Batch extraction asks the database what changed: SELECT * FROM orders WHERE updated_at > :watermark. It is simple and needs no special rights, but it misses deleted rows, sees only the last of several updates between runs, depends on every writer maintaining updated_at, and scans the source on every run. Change data capture (CDC) records the changes themselves, and the cheapest place to read them is the log the database already writes for crash recovery and replication:
| Method | How it finds changes | Deletes | Load on the source | Latency |
|---|---|---|---|---|
| Query-based | Timestamp or ID watermark | Missed | A query per run | Minutes to a day |
| Trigger-based | Triggers fill a change table | Captured | A write per write | Seconds |
| Log-based (Debezium 317,608 ) | Reads the transaction log | Captured | Log reading only | Sub-second |
Log-based CDC also keeps each row's history in order, with transaction boundaries. It costs operational care instead: replication settings, a running connector, and a log that grows if the connector stops (Logical Decoding and Slots). Use batch extraction for small, append-only tables read daily; use CDC for deletes, every intermediate state or freshness in seconds, as with BookNest's order status.