MySQL→BigQuery con CDC: lo que el batch sync pierde

Lo que un sync por comparación se deja en el tintero

La mayoría de pipelines de MySQL hacia un data warehouse siguen el mismo patrón: un job programado hace un SELECT, compara con lo que había en el warehouse ayer y escribe el diff. Según la guía de Erathos sobre CDC de MySQL a BigQuery, ese enfoque tiene tres puntos ciegos estructurales que ningún ajuste de frecuencia resuelve:

Los deletes desaparecen. Si una fila se insertó y luego se borró entre dos ejecuciones, el job solo ve el estado actual, que es ausente. El warehouse nunca se entera de que la fila existió.
Los estados intermedios se evaporan. Una fila actualizada dos veces en una hora aparece en el diff con su valor final; el estado intermedio se perdió.
El costo del escaneo no escala con el volumen de cambios. Cada ejecución del batch relee toda la tabla (o un subconjunto enorme) solo para encontrar las pocas filas que cambiaron.

No es un problema que se solucione corriendo el job más seguido. La fuente lo dice sin rodeos: un pipeline de CDC que corre cada hora es más confiable que un batch sync que corre cada minuto, porque captura lo que pasó, no la última foto.

CDC lee el mismo log que ya usa la replicación interna de MySQL

Change Data Capture (CDC) toma otra ruta: lee el binlog (binary log) que MySQL ya escribe para su propia replicación. Cada INSERT, UPDATE y DELETE se anexa al binlog en el orden en que se commitea, con el estado completo de la fila. No hace falta comparar nada ni inferir ningún diff.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

La implicación práctica para un founder: el warehouse deja de ser una fotografía periódica y pasa a ser un diario de cada cambio. Deletes, updates, estados intermedios, todo preservado, en orden, con timestamp.

Según una comparativa de RisingWave Labs publicada en 2026, las herramientas que implementan este patrón se dividen en dos bandos: CDC basado en logs (que lee el binlog o WAL directamente, con sobrecarga casi nula sobre la base origen) y CDC basado en triggers (que añade hooks a cada tabla, típicamente entre un 5% y 15% de overhead sobre los writes según la comparativa de Pistack de abril de 2026). Para pipelines serios en producción, log-based CDC es el default porque la base origen casi no lo nota.

Lo que MySQL tiene que tener configurado (esto no es opcional)

CDC sobre binlog tiene prerrequisitos reales. Según Erathos, saltarse cualquiera da como resultado pérdida de datos silenciosa: el pipeline corre, pero llega a BigQuery con filas incompletas.

Estos son los no negociables:

binlog_format = ROW con binlog_row_image = FULL. Si row image no es FULL, los eventos de UPDATE y DELETE no llevan el estado completo antes/después, solo las columnas mínimas para aplicar el cambio. Suele no alcanzar para un consumer downstream que necesita la fila entera.
binlog_row_value_options no debe incluir PARTIAL_JSON. Si lo incluye, los updates a columnas JSON loguean solo qué cambió dentro del JSON, no el documento completo. Silencioso, y fácil de no notar hasta que comparás contra la fuente.
Usuario de replicación con privilegios REPLICATION SLAVE, REPLICATION CLIENT, SELECT, RELOAD y SHOW DATABASES sobre *.*.
server-id único para cada cliente de replicación conectado a la base, incluyendo tu conexión de CDC. Las colisiones causan fallos silenciosos muy difíciles de debuggear.
Retención de binlog suficiente para cubrir caídas. El default en MySQL es 30 días. Si tu conexión de CDC está offline más que eso, pierde posición y necesita un snapshot inicial nuevo.

El GRANT básico se ve así:

GRANT SELECT, RELOAD, SHOW DATABASES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'tu_usuario';
FLUSH PRIVILEGES;

Y para verificar configuración:

SHOW VARIABLES LIKE 'log_bin';
SHOW VARIABLES LIKE 'binlog_format';
SHOW VARIABLES LIKE 'binlog_row_image';

Si alguna no vuelve como esperás, el arreglo va en my.cnf y MySQL necesita reiniciarse para aplicarlo. No se aplican estos cambios en producción un viernes a la tarde.

De MySQL a BigQuery: el lado del destino es el fácil

Una vez que CDC está capturando cambios correctamente, el lado del destino es comparativamente simple. Cada evento de cambio se mapea a una operación de fila en BigQuery — insert, update o delete — y el warehouse termina reflejando el historial real de MySQL en lugar de su snapshot actual.

Lo que vale la pena hacer bien no es la carga a BigQuery, es asegurar que lo que llegue allí esté completo. Un pipeline que aterriza datos incompletos a tiempo es peor que uno que ocasionalmente llega unos minutos tarde pero nunca se equivoca. La propiedad más importante de un pipeline de CDC no es la latencia, es la correctitud.

Open source vs. managed: qué hay disponible en 2026

Para un equipo que quiere self-host, tres proyectos open-source dominan el espacio de CDC basado en binlog según la comparativa de Pistack de abril de 2026:

Debezium (Red Hat): el benchmark open-source. 12.650 estrellas en GitHub, soporta MySQL, PostgreSQL, MongoDB, SQL Server y más. Corre sobre Kafka Connect, lo que significa que Kafka es dependencia obligatoria salvo que uses Debezium Server en modo standalone.
Canal (Alibaba): 29.671 estrellas en GitHub, construido específicamente para parseo de binlog de MySQL, simula una réplica de MySQL. Ideal para arquitecturas MySQL-only con alto throughput.
Maxwell’s Daemon: CDC ligero solo para MySQL, salida JSON a Kafka o stdout. Más simple pero con menos actividad de desarrollo que Debezium.

Para equipos que no quieren operar un cluster de Kafka o Kafka Connect, RisingWave ofrece un motor de streaming SQL que usa el mismo Debezium Embedded Engine internamente pero elimina la capa de Kafka: conectás directo a MySQL y consultás los cambios con SQL.

Y para equipos que prefieren tercerizar la operación, plataformas managed como Fivetran, Airbyte y Erathos se encargan de la configuración de binlog, asignación de server-id y la recuperación cuando un binlog se purga antes de que la conexión se ponga al día. Cambiás gasto mensual por no tener que debuggear colisiones de replicación a las 2 AM.

¿Qué significa esto para tu startup?

Para la mayoría de startups en etapa temprana, la respuesta honesta es: probablemente todavía no necesitás CDC. Si estás sincronizando una sola instancia de MySQL a BigQuery una vez por día para analítica básica de producto, un job programado de Fivetran o Airbyte alcanza. El problema de los deletes-que-no-ves empieza a importar cuando consumidores downstream dependen de fidelidad a nivel de evento: reconciliación de facturación, trails de auditoría, event sourcing, feature stores de ML con correctness point-in-time.

Dos acciones concretas:

Diagnosticá primero, decidí después. Antes de migrar a CDC, instrumentá tu pipeline batch actual para loguear cuántas filas se habría perdido: trackeá hard-deletes y multi-updates entre corridas. Si el número es no trivial en una ventana de 7 días, CDC se paga solo.
Si vas self-hosted, presupuestá Kafka. Debezium sin Kafka es Debezium Server en modo standalone, usable, pero perdés fan-out y replayability. Si eso importa (y suele importar para analítica), planificá un cluster de Kafka desde el día uno en lugar de retrofitearlo después.

Conclusión

CDC no hace tu pipeline más rápido, lo hace completo. Para equipos que corren MySQL en producción y BigQuery como capa de analítica, la pregunta no es cómo hago que este sync corra más seguido, sino qué es lo que hoy no estoy pudiendo ver. CDC sobre binlog es la respuesta estándar; la única decisión real es si lo operás vos mismo (Debezium + Kafka, Canal, RisingWave) o pagás a alguien para que lo opere por vos.