Lesson 15 · Senior CDC practice

Snapshots, backfills, and replication-slot safety

How to reason about initial vs incremental snapshot behavior, backfill safety, and the operational importance of updating a source connector without losing its slot.

Your win: explain why adding a table safely is really a slot-preservation story, and how incremental snapshots turn a risky reconfiguration problem into a controlled backfill path.

Why this lesson is really about continuity

People often hear “snapshot” and think the topic is mostly about historical rows. That is only half the story. The stronger operational lesson is about continuity: how do you backfill the rows you missed without breaking the live capture path you already trust?

The earlier CDC lessons are good because they keep connecting mechanism to consequence. This page should be read the same way. The mechanism is incremental snapshot. The consequence is that you can add capture scope without casually risking slot continuity.

In plain English Plain English: backfilling old rows is easy; doing it without losing future changes is the hard part.

Why source recreation is the wrong instinct

At a glance, recreating a connector can feel symmetrical. Change config, recreate, move on. But source connectors and sink connectors are not equally risky. A sink is an applier of derived state. A source is the continuity anchor into the WAL.

That asymmetry is the whole point. Once you see it clearly, the repo’s update-plus-signal path starts looking less like an implementation quirk and more like the right operational design.

The slot-safety rule Updating a source connector plus incremental snapshot is safer than recreation because the slot continuity is preserved while the missing historical rows are backfilled.

What incremental snapshot is buying in practice

It is easy to explain incremental snapshot as “load old rows for a new table.” That is true, but still incomplete. The stronger explanation is that it lets you do that backfill while keeping the running source path intact.

That is why this topic belongs in the senior part of the course. It is not only about feature support. It is about operational judgment under change.

Backend use case In this repo, dbz_signals, IncrementalSnapshot, and the hephaestus update path work together so a new table can be captured and backfilled without throwing away the replication slot.
Common mistake Talking about connector recreation as if source and sink connectors had the same operational risk profile.
Read this next

Signals and backfills together

Revisit Debezium signalling and the repo’s snapshot code so the backfill story stays tied to the slot-safety story.

→ Debezium signalling
→ Repo CDC map

Check yourself (from memory)

Q1. Why is update-plus-incremental-snapshot safer than recreating the source connector?

The safety story is really about continuity of change capture, not only loading old rows.
Why is source recreation riskier than sink recreation in CDC?
recall, then click to reveal
Because the source holds continuity with the WAL through the replication slot. Losing that continuity can risk missing future changes, while a sink is only a downstream applier of derived data.
Want a “should we update this source or recreate it?” operations drill? Ask me.

Sources. Debezium signalling docs; repo CDC map.