Skippr Docs

Appearance

How MotherDuck MERGE Works for CDC Final State ​

April 2026

MotherDuck keeps the warehouse lightweight, but CDC still needs a real final-state design if the tables are going to stay trustworthy.

Short Answer ​

MotherDuck is a good fit for teams that want a lighter warehouse path, but the CDC rules do not disappear just because the stack is smaller. You still need clear row identity, clear replay behavior, and a deliberate final-state table shape.

That is why MERGE semantics matter here too. A compact stack still needs a table people can trust after retries.

Why Teams Struggle with This ​

Small teams often want the warehouse to stay simple, which is reasonable. The trap is assuming simplicity means correctness comes for free.

  • A lightweight destination can still accumulate duplicate or stale rows if identity is vague.
  • Delete behavior becomes confusing when it is not described explicitly.
  • Teams sometimes accept "good enough" CDC until downstream models start compensating for it.
  • Replay bugs cost more when the same people own ingestion and analytics.

How Skippr Handles It ​

Skippr works well in this kind of setup because it keeps the whole path compact: source config, destination config, CDC behavior, and generated dbt bootstrap in one project directory.

That makes MotherDuck a practical option for teams that want less ceremony without giving up reviewable warehouse logic.

  • CDC behavior stays visible in the same project as the destination setup.
  • Business keys can be reviewed before the first warehouse table becomes a dependency.
  • The generated dbt project stays small and understandable.
  • The workflow is easier to teach to a team that does not want a sprawling stack.

What the First Useful Version Looks Like ​

A small stack still benefits from strong contracts.

That is what makes MotherDuck CDC pleasant instead of fragile.