Your Debezium initial snapshot has run eight hours and the source's replication slot keeps growing — what now?

## What is actually happening A Debezium connector's log position is only advanced by the streaming phase. During a classic snapshot there is no streaming phase running, so nothing acknowledges the log. On Postgres that means the replication slot holds a position from before the snapshot started and the server must retain every WAL segment from there onward; on MySQL it means binlog files the connector still needs must not be purged. The retained volume grows with the source's write rate multiplied by the snapshot's duration — completely independent of how large the tables being copied are. A modest table on a very busy database can be a worse problem than a huge table on a quiet one. The failure mode is severe because the pressure lands on the **source**, not on the pipeline. A full disk on the primary is a production outage. That is why the correct first move is not connector tuning; it is capacity triage. ## Triage, in order Establish the numbers before touching anything. How much free space remains on the volume holding the logs, and how fast is retained volume growing per hour? What is the connector's slot or offset lag now? How far through the snapshot is it — rows read versus rows expected, which the connector's progress logging and the source's own statistics can tell you. From those three you get the only decision that matters right now: will the snapshot finish before the disk does? If it will, and with margin, let it finish and fix the approach next time. If it will not, act: raise disk headroom if the platform allows it, or abort the connector and accept dropping the slot, which immediately releases the retained log — at the price of losing the ability to resume from that point, so any subsequent start must be reasoned about from scratch. ## Making the snapshot itself shorter Several levers reduce snapshot duration directly. `snapshot.fetch.size` controls how many rows are pulled per round trip. Some connectors expose `snapshot.max.threads` to snapshot multiple tables in parallel. `snapshot.include.collection.list` restricts which of the captured tables are snapshotted at all, letting you copy in waves. Splitting a very wide capture set across several connectors gives each a smaller snapshot. And `snapshot.select.statement.overrides` can cut a table down to the rows that matter — recent partitions rather than a decade of history. These all help, but they are optimisations of the wrong shape. They shorten the interval in which nothing consumes the log; they do not remove it. ## The structural fix The modern answer inverts the order. Start the connector in a mode that emits no rows — `schema_only`/`no_data` on the schema-history connectors, `never` on Postgres — so it reaches the streaming phase almost immediately. From that moment the slot advances, the source stops accumulating, and the pipeline is current for all new changes. Then backfill history by sending `execute-snapshot` signals per table. Incremental snapshots read in chunks bounded by window markers, interleave with streaming so the log keeps draining, checkpoint their progress in the connector's offsets so a restart resumes at the next chunk, and accept `pause-snapshot` and `stop-snapshot` so you can yield during peak hours. This converts a single unbounded risk window into a controllable background job. It is the reason incremental snapshots exist. ## Prevention Three habits stop this recurring. Do not create the slot or start the connector days before the pipeline is ready — the clock starts when the slot appears, not when data starts flowing. Monitor retained log volume and connector lag as a first-class alert on the **source database**, with a threshold that fires while there is still time to act. And size the plan before deploying: estimate snapshot duration from row counts and observed read throughput, multiply the source's write rate by that duration, and compare the result with free disk. If the arithmetic is uncomfortable, choose the stream-now-backfill-later path from the start rather than discovering the problem at 3 a.m. ## One more restart hazard Be careful about restarting a connector mid-snapshot to "apply a tuning change". On most connectors a classic snapshot that is interrupted begins again from the beginning, so you pay the whole cost twice and extend the retention window rather than shortening it. Some newer connector versions can resume — confirm for the exact connector and version before assuming either way.