Change data capture, or CDC, streams every insert, update, and delete from a database to other systems the instant each change commits. Instead of polling a table on a schedule and diffing the results, a CDC connector reads the database's own transaction log, the durable record every engine already writes before it touches a table, and turns each committed change into a structured event. That single design choice is why CDC scales cleanly where polling does not: it adds almost no load to the source, and it never misses a delete or a rapid update between polling windows. Nearly every downstream system in a modern data stack — a search index, a cache, a warehouse, an analytics store — ends up needing the same feed of changes, which is why CDC has become foundational plumbing rather than a specialized tool built for one integration.
What changed in 2026
- CDC became a built-in cloud database feature. Several managed database services now expose a native change stream without requiring a separate connector to be deployed and operated.
- Schema registries became standard practice. Pairing CDC output with a schema registry catches breaking changes before they reach downstream consumers, instead of failing silently inside a subscriber pipeline.
- CDC feeding lakehouse tables matured. Streaming inserts, updates, and deletes directly into open table formats such as Iceberg and Delta Lake became a common ingestion pattern, replacing nightly full-table reloads.
- Connector operational tooling improved. Managed Kafka Connect and Debezium offerings cut the operational burden that used to make self-hosting a CDC pipeline a significant undertaking on its own.
How it works
Every write to a relational database first lands in a transaction log, the write-ahead log in Postgres or the binlog in MySQL, because the engine needs it for durability and replication regardless of CDC. A log-based connector such as Debezium tails that log directly, not the tables, and emits an event per committed change carrying the operation type and the before and after row images:
{
"op": "u",
"before": { "id": 42, "status": "pending" },
"after": { "id": 42, "status": "paid" },
"ts_ms": 1732900000000
}
Those events publish to a stream, most commonly Kafka, where any number of downstream consumers can subscribe independently: a search index, a cache invalidator, a data warehouse loader, or an audit log. Because each consumer reads from its own position in the stream, adding a new one never requires touching the source database or any existing subscriber, which is the main structural advantage CDC has over a bespoke integration built for a single downstream system.
Where CDC fits in a 2026 stack
| Tool |
Source databases |
Notes |
| Debezium |
Postgres, MySQL, MongoDB, SQL Server, Oracle |
Open source, runs on Kafka Connect, the most widely deployed option |
| AWS DMS |
Most major engines |
Managed, common for both migrations and ongoing replication |
| Managed CDC in ELT platforms |
Many, via connectors |
Bundled into broader data-loading pipelines, lowest setup effort |
| Native cloud change streams |
Cloud-native databases |
Lowest operational overhead if you are already on that platform |
Common mistakes
- Polling instead of reading the log. Polling loses deletes and fast updates that happen between poll windows, and adds read load the log-based approach avoids.
- No schema evolution plan. A column rename or type change on the source breaks downstream consumers unless the pipeline handles schema evolution explicitly.
- Treating CDC as exactly-once by default. Most CDC pipelines deliver at-least-once; consumers need idempotent handling of duplicate events.
- Ignoring the initial snapshot cost. Bootstrapping CDC on a large existing table needs a snapshot phase that can be heavier than the ongoing stream ever is.
- Fanning out consumers without checking replay behavior. A new consumer that needs historical data, not just future changes, requires either a fresh snapshot or a stream with long enough retention to replay from, which is worth confirming before you depend on it.
FAQ
Is CDC the same as database replication?
Related but distinct. Replication copies data to a standby; CDC exposes changes as consumable events for arbitrary downstream consumers, not just a database copy.
Does CDC add meaningful load to the source database?
Log-based CDC adds very little, since it reads a log the engine already writes, unlike polling, which repeatedly queries the live tables.
What happens if the CDC connector goes down?
It resumes from its last committed log position once restarted, as long as log retention has not been truncated past that point.
Can CDC feed a data warehouse directly?
Yes, this is one of its most common uses, often paired with a streaming or batch loader on the consuming end.
Does CDC work with NoSQL databases?
Yes, for engines that expose an equivalent change stream or oplog, such as MongoDB's change streams. The pattern is the same even though the underlying log format differs from a relational write-ahead log.
Where to go next
See streaming vs batch processing for how CDC output typically gets consumed, the outbox pattern explained for a companion technique that produces cleaner application-level events, and what a race condition is for why ordering and idempotency matter once multiple consumers read the same change stream.