CDC (change data capture)
Change data capture (CDC) is a pattern for turning every insert, update and delete in a database into an ordered stream of change events. Log-based CDC reads the database's own transaction log instead of polling tables. Downstream systems such as warehouses, search indexes and caches can then stay in sync within seconds.
How it works
A connector such as Debezium attaches to the database log. In PostgreSQL it reads the write-ahead log (WAL) through a logical replication slot. In MySQL it reads the binary log. Each event carries the row before and after the change, plus its log position, so a restarted connector resumes from the last committed offset. For example, UPDATE orders SET status = 'paid' WHERE id = 42 becomes one event with before.status = 'pending' and after.status = 'paid'.
Why it matters in production
CDC keeps a replication slot or log position open on your primary or replica. If the consumer stalls, the database keeps the log it has not yet read, and disk usage grows until someone notices. Teams need alerts on slot lag and retained log size, not only on the connector's health check.
See also
On the One2N blog
How one parameter stalled Postgres replication with Debezium for 3 weeks
How temporal versioning prevents configuration drift in stream processing
Migrating from AWS Glue to self-hosted ClickHouse: 70% cost reduction for a fintech client
References
