Change Data Capture
Reading a database's own change log instead of asking it questions. What CDC gives you that polling cannot, what it costs the source, and every way it silently loses or reorders changes.
Reading committed changes out of the database's own transaction log, so downstream systems learn what happened instead of repeatedly asking what is true now.
One asks the database what is true now, on a loop. The other observes what the database committed. The difference is not speed — it is which changes are structurally invisible.
An operation, a before image, an after image and source metadata. Which of those you actually receive is decided by the source's configuration, not by CDC.
The source log has a total order and a transaction boundary. Publishing splits both, and every consumer that joins two tables inherits the consequences.
CDC starts from now. Everything that existed before now has to be read separately and stitched to the stream without a gap and without a duplicate that a later ordering guard cannot resolve.
A consumer falls behind. Whether that is an inconvenience or an unrecoverable data loss is decided entirely by whether the connector's position is still inside the source's retained log.
A migration runs on the source at 02:00. Some connectors emit a schema-change event, some silently reshape the payload, some stop. None of them ask you first.