Skippr Docs

Appearance

How to Use MongoDB Change Streams for Warehouse CDC ​

May 2026

MongoDB change streams are useful for warehouse CDC when you treat resume tokens, document identity, and destination behavior as one design problem.

Short Answer ​

Use MongoDB change streams for warehouse CDC when you want ongoing document mutations to flow into final-state warehouse tables without polling full collections repeatedly. The key setup points are simple: MongoDB must run as a replica set or sharded cluster, CDC must be enabled, and the warehouse path needs a clear idea of document identity.

A concrete example helps. If an orders document changes from { _id: 42, status: "placed" } to { _id: 42, status: "shipped" }, the useful outcome is not just "an update event existed." The useful outcome is that the warehouse row keyed by _id = 42 ends up with status = "shipped". That is the level to think at.

Why Teams Struggle with This ​

Teams often get excited when the stream opens and events start flowing. Then they hit the real questions: what identifies one document over time, what happens after a restart, and how do partial document updates become a trustworthy warehouse table?

  • MongoDB change streams require a replica set or sharded cluster, which can surprise teams coming from a single-node development setup.
  • Resume tokens matter because a CDC pipeline that cannot restart cleanly is not really production-ready.
  • Document updates need a stable row identity in the destination, usually the MongoDB _id or another explicit business key.
  • Teams sometimes land raw mutations and call the job done, even though analysts need final-state tables rather than an event diary.

How Skippr Handles It ​

Skippr keeps the source mechanics and the warehouse contract close together. The MongoDB source config, the CDC block, the resume behavior, and the destination merge path all live in one project, so the team can reason about one integration instead of stitching together separate tools.

That matters with change streams because MongoDB updates are document-oriented. Skippr uses fullDocument: updateLookup style behavior to carry the after-image forward, stores resume tokens for restart safety, and then reconciles those changes into warehouse tables that are easier to model on top of.

  • MongoDB CDC support through change streams backed by the oplog.
  • Resume-token-based restart behavior so the stream can continue cleanly after interruptions.
  • A clearer path from document mutations into final-state warehouse rows.
  • Generated dbt project on top of warehouse tables that already reflect a more useful contract.

What the First Useful Version Looks Like ​

MongoDB change streams are not hard because the API is mysterious. They are hard because document mutation semantics and warehouse table semantics are different shapes.

A good setup makes that translation explicit early, with an example row in mind, instead of leaving the meaning to be guessed downstream.