New: Cookbooks and AI ExplanationsStep-by-Step recipes to solve problems connected to Roadmaps and Cheat Sheets. Need more details? Use AI buttons for structured and simple explanations with concrete examples throughout the whole platform.Take a look
Someone deletes a customer in the source database, and the same row is still sitting in your warehouse table a week later.
What you'll have at the end
A downstream table where a source DELETE removes or flags the matching row, confirmed by deleting a test row and checking it's gone
You need
A CDC pipeline already streaming a source table's inserts and updates into a downstream sink table, where a row deleted at the source never disappears from that sink.
Not covered
Coordinating the same deletion across every other place the customer's data lives, such as a cache, a search index, or a backup; this recipe only closes the gap in one sink table.
Leans on
Keep a CDC consumer from doubling a row after it restarts
go there for the same crash-safety and idempotence problem, but for inserts and updates instead of deletes.
Choose log-based or query-based CDC for a source with no log access
go there first if your source can't offer log-based CDC at all, since a query-based connector never produces a delete event to work with.
Checked 26 Aug 2026
Part of the Change Data Capture (CDC) cookbook