Skippr Docs

Appearance

How Kafka CDC Delete Events Behave in a Warehouse ​

May 2026

A Kafka delete message is only part of the story. The warehouse still needs a rule that makes that delete authoritative after retries and replays.

Short Answer ​

In Kafka CDC, a delete is a Debezium message with op: d. In a supported final-state destination, Skippr does not just note that a delete happened. It applies the delete by business key, writes a tombstone with the order token, and ensures that an older competing mutation cannot overwrite the newer delete result.

For example, if a Debezium topic emits a delete for customer id = 42, the warehouse goal is not merely to preserve a raw event. The goal is for the final-state row keyed by id = 42 to be gone, with tombstone protection so a replayed older insert does not restore it later.

Why Teams Struggle with This ​

Kafka makes it easy to see that a delete message existed. It does not by itself guarantee that the destination table will stay deleted after retries, replays, or competing events for the same key.

  • The warehouse still needs an explicit business key for row reconciliation.
  • Delete correctness depends on ordering, not just on the presence of a delete message.
  • Tombstones are what prevent a newer delete from losing to an older replayed insert.
  • If the destination does not support final-state reconciliation, Skippr falls back to CDC-encoded delivery instead of promising warehouse final state.

How Skippr Handles It ​

Skippr is useful here because it connects the Debezium source semantics to the warehouse-side contract. The delete starts as op: d, but the docs keep going and explain how final-state destinations make that delete durable.

That keeps the discussion honest. A delete event is not successful because it was consumed. It is successful because the destination row state converges on deleted and stays there.

  • Kafka delete semantics start from Debezium op: d messages.
  • Final-state destinations record tombstones and apply conditional delete logic automatically.
  • Business keys remain required because reconciliation is per logical row.
  • The destination contract decides whether the outcome is final state or CDC-encoded delivery.

What the First Useful Version Looks Like ​

The useful question for Kafka deletes is not "did we read the message." It is "after replay, is the warehouse row still deleted for the right key."

That is the point where CDC becomes a warehouse correctness problem instead of a transport problem.