Skippr Docs

Appearance

MongoDB CDC to Synapse Final State Guide ​

June 2026

MongoDB to Synapse is an integration where change-stream documents have to be translated into rows that Synapse can reconcile deterministically.

Short Answer ​

MongoDB CDC to Synapse works by taking MongoDB change-stream events and applying them to Synapse with MERGE statements. Skippr adds a _skippr_order_token NVARCHAR(4000) column and a companion tombstone table for each CDC-managed table, so inserts and updates only win when their order token is newer than the row already stored in Synapse.

A concrete example is a support ticket document with _id 901. If MongoDB emits an update that changes priority from "normal" to "urgent", Skippr carries the after image forward and Synapse MERGE updates that row only when the token is newer. If MongoDB emits a delete next, the integration records the tombstone and removes the row from the target table.

Why Teams Struggle with This ​

This integration has two different kinds of prerequisites to respect. MongoDB needs replica-set or sharded-cluster change streams with stored resume tokens, and Synapse needs a valid ADO-style connection string plus write access to the target schema before MERGE can keep the table in final state.

  • Change streams are unavailable on standalone MongoDB deployments.
  • The destination will only stay correct if the same MongoDB document key is used consistently as the row identity in Synapse.
  • Synapse MERGE protects against stale writes through the _skippr_order_token comparison, not by arrival order alone.
  • Deletes still need tombstones because final-state row removal is not enough to block older replays by itself.

How Skippr Handles It ​

Skippr documents the integration clearly enough to keep the moving parts straight. MongoDB supplies insert, update, and delete events plus the resume token. Synapse supplies MERGE-based reconciliation, the order-token column, and the tombstone table. That gives the integration a deterministic rule for what the current row should be.

The result is easier to operate than a hand-built chain of scripts. When a row changes unexpectedly, you can ask whether MongoDB emitted a newer token, whether Synapse accepted it, and whether a tombstone prevented an older replay from winning later.

  • MongoDB change-stream CDC backed by the oplog.
  • Stored resume tokens for restart-safe streaming.
  • Synapse MERGE reconciliation with _skippr_order_token guards.
  • Automatic tombstone tables for delete protection.

What the First Useful Version Looks Like ​

This integration is a good match when Azure Synapse is the reporting destination but MongoDB is the live application store.

The integration succeeds when the document key and the Synapse row key are treated as the same identity from the beginning.