Comparison
Change data capturevsQuery-based CDC
Change data capture
instead of asking the service to publish events, you read the database's own replication log and turn every row change into one.
Deriving a stream of change events from a database's write-ahead log. It guarantees you see every committed change with no application cooperation, which is why it is the standard way to get data out of a legacy system. The events are row-shaped rather than domain-shaped, so consumers end up coupled to the producer's schema.
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 →