Change data capture (CDC): definition & examples

Change data capture (CDC) identifies every insert, update and delete in a source database and delivers those changes downstream, so replicas, caches and analytics stay current without reloading whole tables. The most robust form reads the database’s own transaction log. It sees every change, including deletes, with very low delay and without adding query load.

What is change data capture?

Debezium, the open-source CDC platform, sums up the case for reading the log. Unlike polling or dual writes, log-based CDC ensures all changes are captured, produces change events with very low delay without the CPU cost of frequent polling, needs no change to your data model (no “last updated” column), can capture deletes, and can include the old row state and transaction metadata.¹ In PostgreSQL the mechanism is logical decoding: extracting all persistent changes to a database’s tables into a coherent format that can be read without knowing the database’s internal state.²

Approach	How it works	Catches deletes?	Load on source
Query-based	Poll `WHERE updated_at > last_sync`	No (hard deletes vanish)	Repeated scans
Trigger-based	Triggers write changes to an audit table	Yes	Extra writes on every change
Log-based	Read the transaction log (WAL, binlog)	Yes	Low; reads what the database already writes

Example: enabling CDC on PostgreSQL

Publication and logical slot (requires wal_level = logical)

sql

12345678910-- Choose which tables to stream
CREATE PUBLICATION kimo_pub FOR TABLE orders, customers, subscriptions;

-- Create a slot that remembers the consumer's position
SELECT pg_create_logical_replication_slot('kimo_slot', 'pgoutput');

-- Monitor how much WAL each slot is holding back
SELECT slot_name, active,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained
FROM pg_replication_slots;

Common misconceptions

“CDC means real time.” It means change-based. Delivery can be seconds or batched every few minutes; the point is not rescanning unchanged rows.
“You never need a full load again.” A first snapshot is required, and logs are eventually discarded, so a consumer that falls too far behind needs a new snapshot.¹
“An `updated_at` column is enough.” Only if rows are never hard-deleted and every writer reliably sets it.

How Kimo uses CDC

In Cloud mode, Kimo’s database connectors (PostgreSQL, MySQL and others) use log-based CDC where the source allows it and fall back to cursor columns where it does not, on the sync schedule you set. The incremental sync engine post explains the design, and connecting Postgres covers permissions. Sources in Bridge mode need no CDC at all, because they are queried live through Kimo Bridge.

ELT vs ETL: CDC is the efficient “E” and “L”.
Query pushdown: the alternative to copying data at all.
Data residency: where replicated data ends up.

Frequently asked questions

Does CDC slow down my production database?

Log-based CDC reads the log the database already writes, so overhead is usually small. Enabling logical WAL increases log volume somewhat, and a stalled consumer can retain WAL, so monitor slot lag.

Can CDC capture schema changes?

Many log-based tools emit schema-change events or detect new columns. Plan for them anyway: renamed or dropped columns still break downstream models.

Is CDC the same as replication?

CDC is the capture mechanism. Replication is one use of it; streaming changes into a warehouse, cache or search index are others.

Sources

2 references

Debezium Features (opens in a new tab)
Debezium (Red Hat and community)debezium.io
Advantages of log-based CDC over polling; capturing deletes; snapshots.
Logical Decoding Concepts (opens in a new tab)
PostgreSQL Global Development Grouppostgresql.org
Definition of logical decoding; replication slots retain WAL regardless of consumer state.

External sources were accessed at the time of writing. Kimo product details, customers and figures in examples are illustrative unless a source is cited.

Change data capture