MySQL CDC to BigQuery: what periodic syncs miss, and how binlog avoids it

MySQL CDC to BigQuery: A Step-by-Step Setup Guide MySQL CDC syncs miss deletes and intermediate updates. Learn how binlog-based Change Data Capture works, what MySQL settings it requires, and how to land it reliably in BigQuery. Aug 25, 2026 Most MySQL-to-warehouse pipelines run on the same pattern: a scheduled job selects rows, compares them to what was there before, and writes the difference. It works, until it doesn't. What periodic syncs miss A SELECT -based sync only sees what exists right now. It has no way to know a row existed and was deleted between two runs, no way to see intermediate states of a row that changed more than once, and it puts real load on your production database every time it scans a large table just to find a handful of changed rows. What CDC does differently Change Data Capture reads directly from MySQL's binary log (binlog), the same mechanism MySQL uses internally for replication. Every INSERT, UPDATE, and DELETE is captured as it's written to the log, in order, with the complete row state. Nothing is inferred by comparison. Nothing depends on when a batch job happens to run. This isn't about speed. A CDC pipeline that runs once an hour is still fundamentally more reliable than a batch sync that runs once a minute, because it captures everything that happened , not just the latest snapshot. What has to be true on the MySQL side CDC via binlog has real prerequisites: Binary logging in ROW format, with FULL row images. If binlog…