Change data capture, or CDC, records changes in a source data store so that another system can apply or consume them. A complete replication path combines an established initial state with the subsequent changes needed to keep the target aligned.
The initial snapshot answers what existed at a defined boundary. The change stream answers what happened after the corresponding position. Correct continuity depends on joining those two accounts without unexplained gaps or duplicated business effects.
State and position
A connector needs a position in the source history from which to continue. An offset records progress through that history. The target’s visible state depends on which changes have actually been applied, not merely which events were read.
Lag describes a difference in progress between parts of the path. A running connector can coexist with a target that remains behind. A healthy process indicator therefore does not establish that the target represents the source at the point required for cutover.
The snapshot boundary and streaming position must form a coherent sequence. Otherwise, a change that occurs around the handoff can be omitted or represented twice. The exact mechanism is connector- and database-specific.
Recovery can repeat events
Debezium’s PostgreSQL connector documents duplicate change events during fault recovery. A failure can leave progress acknowledged at one point in the pipeline while another component has already processed additional work.
Replaying from the recorded position restores continuity by presenting changes again. The consumer must interpret those repetitions according to its operation. Replacing a stored value and issuing a new external business action are different effects even when both originate from one change event.
Suppose a replicated update triggers an email. Reapplying the row value can leave the table unchanged while sending the email twice. Data convergence does not by itself establish exactly-once downstream behavior.
Source history is a dependency
A saved offset is useful only while the source can supply the required history. The Debezium connector documents startup failure when its recorded write-ahead-log position is no longer available.
An extended outage therefore creates a recovery requirement beyond restarting the process. The supported response must re-establish a coherent source and target state, including any gap that can no longer be replayed from retained history.
Retention, storage use, and outage tolerance are related design choices. No universal retention interval follows from the word CDC. The relevant duration depends on the history required by the deployed connector and the failures the operating arrangement is expected to survive.
Rows are not the whole database
Replication scope can exclude database objects and operating state. PostgreSQL 18 logical replication does not replicate schema changes or sequence state. Existing identity-column values can match while the subscriber’s next generated identifier remains unsuitable for accepting new writes.
A target intended only for reading has different acceptance needs from one intended to become authoritative. Promotion requires attention to the state and privileges needed for future operation, not only agreement of the copied rows.
Schema change also affects the stream’s interpretation. The source and target must remain compatible for the changes being applied. A pipeline that worked for yesterday’s schema does not establish compatibility with a new field, changed type, or altered relationship.
Acceptance across normal operation and failure
A useful replication assessment covers initial load, ongoing changes, connector restart, extended interruption, schema changes, and target promotion. Each scenario tests a different continuity boundary.
Reconciliation accounts for the selected records and transformations at an agreed comparison point. The operating record identifies unresolved changes, lag, excluded objects, and the recovery path when source history is missing.
CDC is therefore a mechanism for carrying changes, not a complete migration guarantee. Its result becomes dependable only within the capture scope, retained history, consumer behavior, and recovery conditions that have actually been established.