Full load, CDC, and full load plus CDC are often compared as if the main difference were speed. Full load is described as batch, CDC as real time, and full load plus CDC as the obvious choice when both are available.
That framing misses the harder part of the decision.
The right pattern depends on what state the destination needs to hold, whether a trustworthy baseline already exists, and what recovery guarantee the system must provide when something fails. A pipeline can deliver changes in seconds and still produce an incomplete target. Conversely, a full load can be perfectly adequate when there is no requirement to maintain the destination continuously.
The useful question is therefore not simply how fresh does the data need to be? It is how will the destination become complete, stay current, and recover without losing continuity?
Full load: build a baseline, then stop
A full load reads the selected dataset from the source without continuing to follow subsequent changes. It works well for one-time migrations, small reference datasets, reproducible rebuilds, and sources where no usable change mechanism exists.
Its main limitation is straightforward: once the load finishes, the target begins to age.
Running another full load later creates another snapshot. It does not turn the destination into continuously maintained state. As source datasets grow, repeated copies can also become expensive, producing large source reads and increasingly long windows in which the destination is stale.
There is another detail that matters in production: a full load is not automatically a transactionally consistent snapshot.
Depending on the source and connector, it may be a database snapshot with well-defined transactional semantics, a sequence of table scans taken at slightly different times, or an API pagination walk with no global snapshot guarantee. Concurrent writes during the copy can therefore matter, especially when business state spans multiple related tables or objects.
For a one-time copy, that may be acceptable. For a destination expected to represent current operational state, it usually is not enough.
CDC: follow changes from a known point
Change data capture follows inserts, updates, and deletes from a defined source position. Depending on the system, that position might correspond to a MySQL binlog location, PostgreSQL WAL position, Oracle redo position, MongoDB change stream, or another connector-specific mechanism.
CDC is a good fit when the destination already contains a trusted baseline and the requirement is to maintain it from that point forward. It can also be appropriate when the consumer deliberately needs only changes occurring after a defined position.
What CDC does not do is recreate data that existed before it started.
That distinction sounds obvious, but it is one of the easiest ways to build a technically healthy pipeline around a logically incomplete target. If the destination begins with 80% of the required rows, a CDC process can capture every subsequent change correctly and still preserve an incomplete destination indefinitely.
CDC therefore solves continuity after a starting point. It does not, by itself, establish the baseline that makes that continuity meaningful.
Full load plus CDC: build the state and keep it current
For a new destination that needs to become complete and then remain current, full load plus CDC is usually the relevant pattern.
The difficult part is not running a snapshot and a CDC process at roughly the same time. It is making them one continuous, recoverable process.
A reliable implementation needs to establish a source position, build the baseline while changes continue to happen, retain those changes during the copy, catch up once the baseline is complete, and then continue following new changes.
In simplified form:
This handoff is where naive implementations fail.
Starting a snapshot job and a CDC job independently does not establish continuity between them. There may be a gap in which committed changes belong to neither side, or an overlap in which the same change is applied more than once.
Overlap is often manageable when application semantics are explicit and writes are idempotent. A gap is more dangerous because data can disappear silently.
That is why “full load + CDC” should be understood as a single lifecycle rather than two separate features.
A practical way to choose
For most systems, the first decision can be made from a small set of questions.
This table gets you to the likely pattern, but it does not tell you whether that pattern will survive production.
That depends on the operating envelope around it.
The production constraint is continuity, not the label
A saved source position is useful only while the source still retains the history required to resume from it. Log retention therefore has to cover realistic outages, baseline duration, and catch-up time.
Consider a baseline that requires ten hours to copy while the source retains only two hours of change history. Even if CDC works perfectly during normal operation, the system cannot guarantee a recoverable handoff if the required changes disappear before the initial load catches up.
Copy throughput matters for the same reason. Increasing parallelism may shorten a full load, but it can also increase source I/O, locking, network pressure, or load on downstream systems. A faster baseline is useful only if the source can tolerate the way it is achieved.
Catch-up capacity deserves a separate calculation as well. During the initial load, changes continue to accumulate. Once the baseline finishes, the pipeline must apply that backlog faster than new changes are arriving. If the source produces changes at a sustained rate above what the target can absorb after transformations, indexing, and realistic row sizes are included, the pipeline never reaches steady state.
Snapshot semantics also affect the handoff. A transactionally consistent database snapshot gives CDC a different correction problem from a set of independently scanned tables or an API walk where records can change between pages.
This becomes especially important when business state spans multiple objects. Row counts alone are not enough to validate such a baseline. Two datasets can contain the same number of rows while still disagreeing on versions, relationships, or the current value of an entity after catch-up.
The real requirement is not merely that the copy finished. It is that the destination reached a state you can explain and reproduce.
Design the rebuild before you need it
Any destination intended to stay current eventually needs to be rebuilt.
Small reference datasets may simply be replaced by another full load. Larger operational datasets may need an in-place recovery, a parallel rebuild, or a new target generation that is validated before consumers are moved across.
Those decisions should be part of the synchronization design from the beginning.
The source position associated with a baseline should remain tied to the build metadata. If a new generation is built in parallel, the system also needs a clear cutover strategy: how the new target is validated, when writers are switched, how old and new generations are fenced from conflicting ownership, and how consumers avoid reading a partially caught-up replacement.
Failure cases are equally important. What happens if the baseline stops halfway through? What if the saved source position expires before recovery? What if the schema changes while the copy is running?
A synchronization pattern is therefore not just a way to get data from A to B. It is a lifecycle decision covering initialization, continuity, interruption, recovery, validation, and rebuild.
That is also why Tapstate treats initial loading and incremental change as parts of the same operational data path rather than unrelated jobs. For workloads that need maintained current state, the important property is not simply that CDC exists. It is that baseline construction, source progress, catch-up, and continued change processing remain one understandable and recoverable continuum.
The right pattern is the one whose continuity you can demonstrate under the behavior of the actual source—not the one with the most attractive label.
—————————————————
Ready to keep operational data current?
See how Tapstate brings initial load and CDC into one continuous, recoverable data path.
