Why Tombstone Tables Matter for CDC Final State

May 2026

Delete handling gets much easier to reason about when tombstones are treated as part of the warehouse contract instead of an awkward side effect.

Short Answer

Tombstone tables matter because deletes are often the hardest part of CDC to explain after the fact. A row disappears from the final-state table, but the team still needs evidence that the delete happened and how it was processed.

That is what tombstones give you: a visible record of delete intent without forcing the final-state table to carry every historical detail.

Why Teams Struggle with This

Hard deletes can make warehouse readers happy in the short term, but they often make debugging and auditing harder. Once the row is gone, the reasoning can disappear with it.

• A final-state table alone may not explain why a row disappeared.
• Replay bugs around deletes are harder to inspect without a separate delete record.
• Teams often mix operational deletion logic with analytical modeling concerns.
• Audit conversations become slower when delete intent is invisible.

How Skippr Handles It

Skippr is a good fit for this topic because CDC is treated as a warehouse contract, not just transport. Delete handling can be designed deliberately instead of being rediscovered downstream.

That makes the generated dbt project more useful too, because models can build on top of clearer source-of-truth behavior.

• Delete intent can stay visible alongside final-state delivery.
• Warehouse readers get cleaner tables without losing operational traceability.
• Teams can discuss deletion semantics before marts depend on them.
• The dbt layer inherits a clearer contract.

What the First Useful Version Looks Like

Not every pipeline needs a separate tombstone table.

But every pipeline should make delete behavior explainable, and tombstones are often the cleanest way to do that.