How PostgreSQL CDC Delete Events Behave in a Warehouse

May 2026

A PostgreSQL delete reaches the warehouse with more than row absence. It brings ordering from the WAL and a final-state contract that keeps older replays from winning.

Short Answer

In PostgreSQL CDC, a delete starts as a row-level delete from logical replication. In a supported final-state destination, Skippr reconciles that mutation by business key, records a tombstone with the order token, and removes the row from the target table. The docs explicitly use PostgreSQL LSN as an example of the native log position that can be turned into the lexicographically sortable order token.

That means a delete is not just "the row went away in the source." It is "the warehouse now has a newer delete for this logical row than any older insert or update." If order id = 42 is deleted in PostgreSQL, an older replayed insert for id = 42 should not be able to restore it because the delete has the newer order token.

Why Teams Struggle with This

Delete bugs usually show up after retries. The event was captured correctly, but the warehouse still needs a rule for which competing mutation is newer and whether a deleted key is allowed to come back.

• Business keys are required because reconciliation is defined per logical row.
• The order token matters because older source mutations must lose to newer deletes.
• Tombstones are what keep a replayed older insert from resurrecting a deleted row.
• If the destination cannot do final-state reconciliation, the correct contract is CDC-encoded delivery instead.

How Skippr Handles It

Skippr is a strong fit for PostgreSQL deletes because the source ordering story is native and explicit. Logical replication provides the WAL position, and the destination docs explain how that ordering is used to protect final-state tables.

That gives operators a clear explanation path: the delete came from the WAL, the warehouse stored a tombstone for the same logical row, and older conflicting mutations were rejected during apply.

• PostgreSQL delete mutations originate from WAL logical replication.
• Order tokens can be derived from native log position such as PostgreSQL LSN.
• Final-state destinations create companion tombstone tables automatically.
• Tombstones prevent older replayed inserts from reviving deleted rows.

What the First Useful Version Looks Like

The right way to evaluate a PostgreSQL delete path is to ask whether the warehouse keeps the delete authoritative after replay. If not, the pipeline has transport but not trustworthy final-state behavior.

That is why the tombstone rule matters so much.