Skippr Docs

Appearance

MySQL CDC to MotherDuck Final State Guide ​

June 2026

MySQL to MotherDuck stays understandable when the team thinks in row events, tokens, and final-state rows instead of append-only loads.

Short Answer ​

MySQL CDC to MotherDuck works by reading MySQL row-level binlog events and reconciling them with MotherDuck using DuckDB-style MERGE behavior. In Skippr, upserts use INSERT OR REPLACE with a subquery that checks order-token ordering, and deletes use tombstone inserts plus DELETE with a tombstone join. That gives the pipeline exactly-once final-state behavior when the same key shows up more than once.

A concrete example is customers.id 77 moving from tier "standard" to "plus". MySQL emits an UPDATE_ROWS event with the full row image, and MotherDuck only replaces the current row if the incoming _skippr_order_token is newer. If that customer row is later deleted, the tombstone table records the delete token so an older replayed insert does not restore the row.

Why Teams Struggle with This ​

This integration is simpler to operate than a staged cloud warehouse path, but it still depends on the same CDC fundamentals. MySQL has to produce complete row events, and MotherDuck still needs a stable row key plus token-based ordering to preserve the right final state.

  • MySQL CDC depends on ROW binlog format and FULL row images.
  • Restart safety comes from storing the binlog filename and position, not from guessing where the stream left off.
  • MotherDuck upserts are guarded by token ordering, so a replayed older event should never replace a newer row.
  • Delete correctness depends on companion tombstone tables rather than on hard deletes alone.

How Skippr Handles It ​

Skippr makes this integration readable from end to end. The source side records MySQL binlog positions after each committed batch. The destination side creates the _skippr_order_token column and tombstone table automatically, then applies the documented MotherDuck reconciliation logic. You do not have to invent a separate replay policy downstream.

That clarity matters when a table changes unexpectedly. You can inspect the source event type, the stored ordering point, and the destination rule that decided whether the row was replaced, ignored, or deleted.

  • MySQL row-event CDC with durable resume positions.
  • MotherDuck reconciliation through INSERT OR REPLACE plus order-token checks.
  • Automatic tombstone tables for deletes.
  • Exactly-once final-state behavior backed by MotherDuck and DuckDB transactions.

What the First Useful Version Looks Like ​

This integration is a strong option when MotherDuck is the warehouse the team actually queries and MySQL is the source of truth.

The useful design review is not about volume first; it is about whether every MySQL key has one clear MotherDuck row identity.