Skippr Docs

Appearance

Kafka CDC to MotherDuck Final-State Guide ​

June 2026

Kafka to MotherDuck CDC can stay simple, but it still needs real rules for keys, deletes, and stale replays.

Short Answer ​

Kafka CDC to MotherDuck works by converting Debezium topic messages into row changes that a DuckDB-style warehouse can reconcile. Skippr reads create, update, and delete events from Kafka, preserves the key fields that identify the row, and applies final-state logic in MotherDuck so the table reflects the latest valid record instead of every message ever seen.

What changes for MotherDuck is not the core CDC contract but the footprint of the stack. You still need order-token guards and tombstone tables. The difference is that the destination path stays compact, which makes it a good fit for teams that want CDC correctness without a heavier warehouse surface.

Why Teams Struggle with This ​

The small-team trap here is to assume that a lightweight destination means a relaxed data contract. Kafka does not become simpler just because the warehouse is smaller.

  • Consumer offsets do not replace business keys when defining the target row.
  • Debezium delete events need explicit delete handling in the warehouse.
  • A replayed message can still be stale even if it arrives through a healthy consumer group.
  • Teams often land topic payloads quickly but delay the final-state table design.

How Skippr Handles It ​

Skippr follows the documented Kafka setup: Debezium envelope parsing plus stable consumer-group resume. That makes the source side durable and easy to reason about after restarts.

On MotherDuck, Skippr adds _skippr_order_token and tombstone tables, then applies documented final-state reconciliation with DuckDB semantics. The resulting table stays small-team friendly without becoming vague.

  • Kafka resume uses committed consumer group offsets.
  • Debezium key fields become the MotherDuck row identity.
  • Order-token guards stop stale topic replays from winning.
  • Tombstones make delete behavior inspectable.

What the First Useful Version Looks Like ​

Choose this setup when Kafka is non-negotiable as the transport layer but the warehouse stack should stay lean.

The integration succeeds when message semantics are translated into row semantics early, not left for ad hoc cleanup later.