Skippr Docs

Appearance

MongoDB CDC to Snowflake Final State Guide ​

June 2026

MongoDB to Snowflake works when document mutations and Snowflake MERGE rules are designed as one integration instead of two disconnected systems.

Short Answer ​

MongoDB CDC to Snowflake works by reading MongoDB change streams and applying those insert, update, and delete events with Snowflake MERGE DML. Skippr creates the _skippr_order_token column and a skippr_tombstones companion table automatically, so Snowflake only updates a row when the incoming token is newer than the token already stored.

Consider a customer profile document with _id 88. An update that changes the shipping city arrives from MongoDB as an update event with the full after image, and Snowflake MERGE updates the row for _id 88 if that order token wins. If the customer document is deleted later, Skippr writes the tombstone and removes the row so an older replayed insert does not revive it.

Why Teams Struggle with This ​

This integration looks simple from far away because Snowflake has strong MERGE support, but the source side still matters. MongoDB CDC only exists on replica sets or sharded clusters, and restart safety depends on preserving the resume token from the last committed batch.

  • MongoDB updates need the after image to make sense as final-state rows in Snowflake.
  • Snowflake MERGE protects against stale writes only if the integration preserves a stable key and compares order tokens every time.
  • Deletes need both row removal and tombstone tracking to stop ghost resurrections.
  • Source restart behavior is token-based, so losing the resume token means losing the clean handoff point.

How Skippr Handles It ​

Skippr keeps the integration grounded in the documented mechanics. MongoDB contributes change-stream operations plus the resume token. Snowflake contributes MERGE DML, automatic order-token columns, and automatic tombstone tables. The pipeline treats those as one final-state contract rather than hoping warehouse SQL repairs source ambiguity later.

That is especially useful when a team wants to explain a specific row. You can trace the last winning mutation, confirm that Snowflake rejected stale replays, and verify that deletes leave behind an explicit tombstone record.

  • MongoDB change-stream CDC with insert, update, and delete coverage.
  • Resume-after restarts driven by stored MongoDB resume tokens.
  • Snowflake MERGE updates guarded by _skippr_order_token comparisons.
  • Automatic tombstone tables for delete protection.

What the First Useful Version Looks Like ​

Use this integration when MongoDB holds operational documents but Snowflake is where analytics teams expect the current version of each entity.

The practical checkpoint is not just whether events land; it is whether a replayed older mutation can lose cleanly every time.