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
Inserts land fine, but every update or delete Debezium sends through shows up as a brand new row instead.
What you'll have at the end
A Spark Structured Streaming job that applies every Debezium change to the Iceberg table with one MERGE per micro-batch, keyed on the primary key, so an update replaces the existing row, a delete removes it, and two changes to the same key in one batch collapse to a single write.
You need
A Debezium connector already streaming a table's raw change events into a Kafka topic, and a target Iceberg table (format version 2 or later) with that table's primary key already set as its identifier column.
Not covered
Setting up the Debezium source connector itself, and choosing copy-on-write versus merge-on-read for the target table, which the sibling write-mode recipe already covers.
Leans on
Copy-on-write or merge-on-read: pick the write mode for a table with constant updates
a merge running on every micro-batch writes small deletes and updates continuously, and copy-on-write's whole-file rewrite on each one gets expensive fast; that recipe measures the switch to merge-on-read
A lakehouse query keeps slowing down as manifest bloat builds up
a merge committing on every micro-batch adds a new manifest each time, and reads on this table will slow down long before storage does; that recipe catches it
Checked 26 Aug 2026
Part of the Data Lakehouse cookbook