Skippr Docs

Appearance

How MotherDuck Handles CDC Replay Safety ​

May 2026

MotherDuck replay safety stays simple when you reduce it to one rule: only newer state should replace the row that is already there.

Short Answer ​

MotherDuck handles CDC replay safety by applying row changes with a guarded upsert pattern: only replace the current row when the incoming _skippr_order_token is newer than the token already stored on that business key. If an older mutation is replayed, it should not win.

Delete safety uses the same idea. Skippr records deletes in a companion tombstone table so an old insert cannot reappear after a newer delete unless its order token proves it is actually the later event.

Why Teams Struggle with This ​

That matters because a smaller warehouse does not remove CDC edge cases. Teams often pick MotherDuck to keep the stack light, but retries, restarts, and replay windows still exist. The destination still needs a clear answer to what should happen when the same key is seen again.

  • A lightweight warehouse is still vulnerable to stale replays if row freshness is not checked.
  • Delete handling needs an auditable record or a replayed insert can look legitimate.
  • Business keys matter just as much here as they do in larger warehouse platforms.
  • A small team usually feels replay bugs faster because the same people own ingestion and analytics.

How Skippr Handles It ​

Skippr keeps MotherDuck replay safety understandable by making the ordering rule part of the destination design. CDC-managed tables get _skippr_order_token, tombstone companions, and exactly-once final-state behavior through MotherDuck and DuckDB transactional semantics.

A concrete example: if account_id = 12 is deleted and an older insert for account_id = 12 is replayed during a retry, the tombstone record with the newer order token blocks the stale insert. The row stays deleted, which is the whole point of replay safety.

  • MotherDuck CDC in Skippr uses DuckDB-style merge semantics with order-token guards.
  • Tombstone tables are created automatically for anti-resurrection protection.
  • MotherDuck inherits DuckDB ACID guarantees for final-state application.
  • The resulting tables stay small enough for teams to inspect without losing correctness.

What the First Useful Version Looks Like ​

MotherDuck is a good reminder that replay safety is about data rules, not platform size.

If newer-wins logic and tombstones are explicit, a compact stack can still deliver trustworthy final-state tables.