Skippr Docs

Appearance

MySQL CDC to Snowflake Final State Guide ​

June 2026

MySQL to Snowflake is easiest to trust when the source row events and the Snowflake MERGE contract are reviewed as one path.

Short Answer ​

MySQL CDC to Snowflake works by capturing MySQL row events from the binlog and reconciling them with Snowflake MERGE DML. Skippr adds a _skippr_order_token VARCHAR column to each CDC-managed table and creates the companion tombstone table automatically, so Snowflake updates a row only when the incoming token is greater than the existing one.

Imagine products.id 205 changing price from 19.99 to 24.99. MySQL emits an UPDATE_ROWS event with the full row image, and Snowflake MERGE updates that row if the new token is newer than what the table already stores. If products.id 205 is deleted later, Skippr writes the tombstone and removes the row so an older replayed insert cannot restore it.

Why Teams Struggle with This ​

This integration depends on clean source fidelity and clean warehouse reconciliation. MySQL has to provide complete row-level events, and Snowflake has to apply them through MERGE rather than through append-only loading that leaves ordering ambiguities for later.

  • MySQL CDC needs ROW binlog format and FULL row images.
  • Restart safety depends on preserving the stored binlog filename and position.
  • Snowflake MERGE protects the final-state table from stale writes only when the integration preserves a stable key.
  • Deletes need tombstones because removing the row alone does not explain which delete token won.

How Skippr Handles It ​

Skippr gives the integration a documented handoff. The source side stores the binlog position after each committed batch. The destination side uses Snowflake MERGE, automatic order-token columns, and automatic tombstone tables. Those are the parts that keep the table in current state after retries or restarts.

That makes Snowflake easier to operate as a final-state destination. A bad replay does not become a mystery; you can check whether the incoming token was older and whether the tombstone already recorded a newer delete.

  • MySQL CDC support for WRITE_ROWS, UPDATE_ROWS, and DELETE_ROWS.
  • Durable resume from stored binlog filename and position.
  • Snowflake MERGE with _skippr_order_token comparison.
  • Automatic tombstone tables that stop deleted keys from returning.

What the First Useful Version Looks Like ​

Choose this integration when Snowflake is where the team wants query-ready current rows, not raw mutation logs.

The healthy mindset is to ask whether each MySQL row event helps Snowflake converge on the right final row, not whether the event merely arrived.