The naive way to keep two systems in sync is to copy everything from the source to the target on a schedule and hope the timing is reasonable. That works until the source gets large, at which point re-copying it all every cycle becomes slow, expensive, and disruptive. Change data capture is the more disciplined alternative: instead of re-reading the whole source, it detects just the records that changed and moves only those downstream. This guide explains how CDC works, the difference between log-based and query-based approaches, and where it fits when syncing configuration and asset data into a SCADA or cloud platform.
Change Data Capture in one line: Change data capture (CDC) is a technique for identifying and capturing only the records that have changed in a source - typically a database - and delivering those changes downstream, rather than repeatedly scanning and copying the entire dataset. It lets a target stay in sync with a source incrementally and efficiently, and it can turn database changes into a stream of insert, update, and delete events that other systems consume as they happen.
The core idea of CDC is to treat change itself as the thing worth moving. A source dataset may hold millions of records, but between one sync and the next only a small fraction of them typically change. Re-extracting the whole dataset to find that fraction wastes time, network, and load on the source, and it forces the target to reconcile a full copy each time. CDC instead identifies the specific rows that were inserted, updated, or deleted since the last sync and ships only those, so the work done is proportional to how much actually changed rather than to how big the dataset is.
Because it captures changes as discrete events, CDC naturally produces a stream rather than a snapshot. Each captured change carries what happened - an insert, an update, or a delete - along with the affected record and often its before and after values. Downstream systems can apply those changes to keep their own copy current, or react to them as events, for example triggering a workflow when a particular field flips. This event orientation is what makes CDC a foundation for near-real-time integration: changes propagate shortly after they occur instead of waiting for the next full batch.
The main challenge CDC has to handle well is deletes and correctness. A full re-copy naturally reflects deletions because the removed record simply is not in the new copy, whereas an incremental approach must explicitly detect that a record disappeared and propagate that removal, or the target will keep stale rows forever. Handling deletes, ordering changes correctly, and recovering cleanly after an interruption are what separate a robust CDC implementation from a fragile one.
Query-based CDC finds changes by asking the source. It relies on the data itself carrying evidence of change - most commonly a last-modified timestamp column or a monotonically increasing version number - and periodically queries for rows whose marker is newer than the last time it looked. It is straightforward to set up because it needs no special database privileges beyond reading the table, and it works against sources you cannot instrument deeply. Its weaknesses are that it can miss deletes entirely, since a deleted row leaves nothing to query, it depends on the source diligently maintaining an accurate change marker, and its polling interval bounds how fresh the target can be.
Log-based CDC reads the database's own transaction log, the internal record every relational database keeps of the changes it commits for durability and replication. Because every insert, update, and delete passes through that log, reading it captures all changes, including deletes, with minimal additional load on the source and without depending on application-maintained markers. It is the approach that most closely approximates a true real-time stream of database changes, and it is what serious replication and streaming pipelines tend to use. The trade-offs are that it requires access to and understanding of the specific database's log format and usually elevated privileges to read it, so it is more involved to set up and more tightly coupled to the source technology.
Choosing between them is a balance of fidelity and effort. Query-based CDC is often good enough for slowly changing reference data where a short delay and imperfect delete handling are acceptable and simplicity matters. Log-based CDC is the right choice when completeness, deletes, and low latency are important and you can obtain the necessary access to the source. Many integrations use query-based CDC as a pragmatic starting point and move to log-based only when its limits begin to bite.
On the field side of an operation, the analogue of CDC is report-by-exception: an RTU or field device sends a reading only when it changes beyond a deadband, rather than reporting on every poll, which conserves bandwidth on constrained links and is baked into protocols like DNP3. CDC is the same principle applied to the data side - to the databases holding configuration, asset registries, and reference information rather than to live telemetry. The two are complementary: report-by-exception keeps live measurements efficient on the wire, while CDC keeps the slower-moving structural data in sync between systems of record and the monitoring platform.
Where CDC earns its keep in a SCADA context is in propagating changes to configuration and asset data. When a well is added, an asset is renamed, a tag registry is updated, or a piece of reference data changes in an upstream system of record, CDC can stream that single change into a cloud SCADA so the platform's view stays current without re-importing an entire asset list every cycle. That keeps the monitoring platform aligned with the enterprise's master data quickly and cheaply, which matters when reports and dashboards depend on the asset picture being right.
A cloud SCADA such as Merobix benefits from receiving these changes incrementally because it is already handling a continuous flow of live measurements and does not want a heavy periodic reload of structural data competing with that. Feeding configuration and asset updates in as a stream of changes lets the platform reflect an addition or a rename shortly after it happens in the upstream system, so the live operational view and the enterprise's master data stay in step. In effect, CDC on the data side and report-by-exception on the field side together let both the fast and the slow data reach the platform efficiently.
Query-based CDC finds changes by periodically querying the source for rows whose timestamp or version marker is newer than last time, which is simple but can miss deletes and depends on an accurate change marker. Log-based CDC reads the database's own transaction log, so it captures every insert, update, and delete with low overhead and near-real-time latency, at the cost of more involved setup and elevated access to the source.
They apply the same principle in different places. Report-by-exception is a field technique where an RTU sends a reading only when it changes beyond a deadband, saving bandwidth on live telemetry. CDC applies to the data side, streaming only changed rows from databases holding configuration and asset information. One keeps live measurements efficient, the other keeps structural data in sync between systems.
A full copy re-reads and re-transfers the entire source every cycle, which becomes slow, expensive, and disruptive as the source grows. CDC moves only the records that actually changed, so the work is proportional to the amount of change rather than the size of the dataset. It also produces a stream of change events, allowing near-real-time sync and event-driven reactions instead of waiting for the next batch.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.