How Redshift MERGE Semantics Work for CDC Final State

April 2026

Redshift CDC usually succeeds or fails on staging discipline and row identity, not on whether events can be copied in.

Short Answer

Redshift CDC final state usually depends on a staged merge pattern: land changes cleanly, reconcile by business key, and make delete behavior explicit. That is what turns change events into a table the warehouse can rely on.

The hard part is not moving the bytes. It is making sure the retry path and the merge path agree on what one row means.

Why Teams Struggle with This

Redshift is often introduced late in the design, after the source stream is already working. That leads teams to discover warehouse semantics only after the first replay, backfill, or delete edge case.

• Staging is treated as temporary plumbing instead of part of the correctness model.
• Merge keys are chosen too late or inherited from a weak source identifier.
• Delete behavior is vague, which makes downstream models guess what "current row" means.
• Teams end up debugging replay outcomes instead of reviewing the data contract up front.

How Skippr Handles It

Skippr helps by making Redshift behavior part of the same project as the source CDC setup. That makes the warehouse semantics visible early, before a team has already built assumptions on top of the wrong table shape.

It also keeps the handoff into generated dbt models cleaner, because the destination table is already designed around final-state expectations.

• CDC config and Redshift reconciliation stay in one execution path.
• Business keys are reviewed where they matter most.
• Delete handling is defined closer to ingestion, not left for cleanup models.
• The generated dbt project can start from tables with a clearer contract.

What the First Useful Version Looks Like

When Redshift CDC feels flaky, the root cause is often not Redshift. It is usually an unclear final-state design showing up in Redshift first.

Fix the contract there, and the rest of the stack gets quieter.