How Databricks MERGE Works for CDC Final State

April 2026

Databricks CDC is mostly a question of table contract clarity: keys, ordering, and what should happen when the same change is seen twice.

Short Answer

Databricks MERGE is the mechanism that makes CDC useful to warehouse readers. It takes raw change events and reconciles them into a table shape the rest of the project can build on.

That only works well when row identity and replay behavior are decided up front. Otherwise the MERGE statement becomes the place where design ambiguity turns into broken state.

Why Teams Struggle with This

Delta tables make it easy to store large histories. They do not remove the need to decide what the current row should be after retries, updates, and deletes.

• A MERGE can be syntactically correct while still encoding the wrong business logic.
• Late-arriving updates become confusing if the ordering signal is weak.
• Delete semantics often get deferred until downstream cleanup, which spreads the problem.
• Teams can mistake table availability for table correctness.

How Skippr Handles It

Skippr treats Databricks destination behavior as part of the CDC setup rather than a separate downstream project. That helps teams define keys and expected warehouse state before the first production replay.

The benefit shows up immediately in the generated dbt project, because the upstream table contract is already clearer.

• Source CDC settings and Databricks reconciliation are reviewed together.
• Business keys stay visible in the pipeline config.
• Warehouse correctness is discussed before analytics models depend on the table.
• Generated dbt models start from a stronger destination contract.

What the First Useful Version Looks Like

Databricks is a good destination for CDC when the merge contract is explicit.

The work is not avoiding MERGE. The work is giving MERGE the right rules.