Which CDC tools read database logs instead of querying tables?
Polling tools ask the database "what changed?" again and again. Log-based capture reads the transaction log the database already writes, which is why it can be both lower-impact and lower-latency.
Log-based CDC parses the source database's native transaction log with read-only access. No triggers, no shadow tables, no repeated table scans — so capture cost does not scale with table size and lag can stay under a minute without loading production.
What each log actually contains
"Reads the log" is not one technique. Each engine exposes different information, and the details decide which change types you can reconstruct faithfully.
| Source | Log read | Typical access path | Practical note |
|---|---|---|---|
| Oracle | Redo log | LogMiner or XStream | Supplemental logging and archive retention decide what is recoverable |
| MySQL | binlog | ROW-based replication stream | ROW format is required; STATEMENT format loses row images |
| PostgreSQL | WAL | Logical decoding through a replication slot | Slot retention must be monitored or WAL can accumulate |
| SQL Server | Transaction log | CDC capture instances | Change retention is bounded by the capture job window |
| KingbaseES | WAL | Logical decoding | Same slot-retention discipline as PostgreSQL |
| DM / Dameng | Redo | Native log reader | Verify the database mode and archiving configuration |
Because the log already contains the before-and-after image of each row, a log-based tool does not need to compare table snapshots. That removes the scan entirely, which is the single biggest source of read load in polling designs. The trade-off moves to the source configuration: retention windows, supplemental logging and replication slots all have to be set correctly, and a misconfigured slot can silently accumulate storage.
Bridge reads these logs as a lightweight process beside the database. The technique is covered by a granted patent for non-intrusive high-speed incremental extraction, and the operational discipline — retention checks, slot monitoring, offset checkpointing — is built into the run cockpit.
Log-based capture is the right choice if…
- ✓Source tables are large and a periodic scan would show up in production
- ✓You need sub-minute freshness rather than hourly batches
- ✓You can enable the required logging configuration on the source
- ✓You need deletes and updates, not just new rows
Log-based capture is unnecessary if…
- ×A nightly batch already meets the requirement
- ×The source cannot enable log retention or replication slots
- ×You only ever append new rows and can use file drops
- ×The database is a read-only replica you cannot configure
CDC, answered
Does reading the log put load on the source database?
Far less than polling. Log parsing does not scan tables; the measurable load comes from log retention and the read of the log stream itself. In typical deployments capture lag is 40–60s at P95 without a measurable impact on source query latency.
What happens on first run — is there a full copy?
Yes. An initial consistent snapshot establishes the baseline, then capture resumes from the corresponding log position so no change is lost between snapshot and streaming.
Can it capture deletes and updates?
Yes. The log carries the row image for inserts, updates and deletes, which is the main reason to read it rather than diff snapshots.
Which databases are supported?
Oracle (Redo), MySQL (binlog), PostgreSQL (WAL), alongside 100+ connectors for other systems. The connector catalog lists versions and known limitations.
Read your logs, not your tables
Start with one high-churn table and measure source impact before you migrate the rest.