How MongoDB CDC Delete Events Behave in a Warehouse

May 2026

A MongoDB delete should end in a deleted warehouse row, not just a logged event. Tombstones are what make that warehouse result durable.

Short Answer

In MongoDB CDC, a delete begins as a change-stream delete event. In a supported final-state destination, Skippr reconciles that event by business key, records a tombstone with the order token, and removes the current row from the target table. That is the step that turns document deletion into reliable warehouse state.

For example, if document _id = 42 is deleted from the source collection and _id is the business key used for reconciliation, the expected warehouse result is that the row for that logical document disappears and stays gone unless a newer insert for the same key arrives later. An older replayed mutation should not be able to undo that delete.

Why Teams Struggle with This

Deletes are where CDC often becomes vague. A document vanishes from the source, but the warehouse still needs a durable rule for how to interpret competing older and newer events for the same logical row.

• Delete correctness still depends on a stable business key such as the field used to identify the logical document.
• A simple hard delete in the destination is not enough to protect against replay or out-of-order writes.
• Tombstones are what keep a newer delete authoritative when an older insert or update is replayed later.
• If the destination cannot support final-state reconciliation, the correct guarantee is CDC-encoded delivery instead.

How Skippr Handles It

Skippr is helpful here because the MongoDB source mechanics and the warehouse contract are documented as one system. The source supplies delete events from change streams, and the destination docs explain how those deletes become tombstones and final-state table changes.

That means a team can reason about a specific deleted document all the way through the pipeline instead of stopping at the event stream and hoping downstream SQL will sort it out.

• MongoDB change-stream deletes become delete mutations in the CDC path.
• Final-state destinations create companion tombstone tables automatically.
• A tombstone protects against older replayed mutations resurrecting the deleted row.
• Business keys stay central because reconciliation is defined per logical row.

What the First Useful Version Looks Like

MongoDB delete handling is successful when the warehouse answer is stable after replay: the row is deleted for the right key, and older events cannot reverse that outcome.

That is exactly why final-state destinations keep tombstones next to the main table.