Comparison
Log-based CDCvsQuery-based CDC
Log-based CDC
you tail the database's own replication log, so a delete and a mid-second update both come through without the source running a single extra query.
Capturing changes by reading the database's write-ahead or binary log, the same feed a replica consumes. Because the log is the truth of what happened, you get every intermediate state, hard deletes and ordering for free, and you put no query load on the source. The price is operational: it needs a privileged connection, it is coupled to the source's storage engine and version, and if your consumer is down long enough for the log to be rotated away, recovery means a new snapshot.
Full entry →Query-based CDC
you poll the source every few minutes with a where-clause on updated_at, and a row deleted outright simply stops appearing.
Capturing changes by repeatedly querying the source for rows whose timestamp or version has moved. It needs nothing but a read connection, which is why it is what you build first and what you can point at a vendor's API. It cannot see hard deletes, it misses intermediate values when a row changes twice between polls, and every poll is real load on a production database — the three reasons teams eventually move to the log.
Full entry →