How MySQL CDC Delete Events Behave in a Warehouse

May 2026

A MySQL delete reaches the warehouse as more than a removed row. It becomes a keyed delete plus ordering and tombstone rules that keep older replays from winning.

Short Answer

In MySQL CDC, a delete starts as a DELETE_ROWS binlog event. In a supported final-state destination, Skippr applies that delete by business key, records a tombstone, and uses the source ordering metadata to ensure that an older competing mutation cannot override the delete. The docs explicitly name MySQL binlog position as one example of the native log position used to derive order tokens.

That matters in practical terms. If customer id = 42 is deleted in MySQL, the warehouse result should be that the row for id = 42 is gone and stays gone unless a newer insert for that key appears later. A replay of an older insert should lose because its order token is older than the delete tombstone.

Why Teams Struggle with This

Delete handling is where "we captured the event" stops being enough. A warehouse table needs a durable way to decide which mutation is newer and whether a deleted key is allowed to come back.

• The business key is mandatory because delete reconciliation is per logical row, not per file or batch.
• Order-token comparison is what stops an older replay from undoing a newer delete.
• The tombstone table preserves delete intent so the final-state table can stay clean without losing replay protection.
• If the destination cannot do final-state reconciliation, the correct outcome is CDC-encoded delivery instead.

How Skippr Handles It

Skippr is especially useful for MySQL deletes because the source ordering story is documented. The warehouse does not have to guess which change is newer. It can use the native log ordering that the CDC contract already recognizes.

That makes delete behavior much easier to explain. The source says a row was deleted, and the destination records enough information to make that delete stay authoritative across retries.

• MySQL deletes originate as DELETE_ROWS binlog events.
• Order tokens can be derived from native log position such as MySQL binlog position.
• Final-state destinations create tombstone tables automatically.
• Tombstones prevent older replayed inserts from resurrecting deleted rows.

What the First Useful Version Looks Like

A good MySQL delete path is one where the warehouse answer is stable after replay: the row is deleted for the right key, and older source history cannot change that result.

That is the real value of combining order tokens with tombstones.