Tu MySQL emite eventos de CDC gratis: los binlog. La mayoría de los equipos los rotan y los tiran. Otros montan un pipeline Debezium-Kafka-Snowflake para hacer analytics y gastan 40k USD/mes.
Hay una tercera vía: con…
Tu MySQL emite eventos de CDC gratis: los binlog. La mayoría de los equipos los rotan y los tiran. Otros montan un pipeline Debezium-Kafka-Snowflake para hacer analytics y gastan 40k USD/mes.
Hay una tercera vía: convertir el binlog en un lakehouse consultable con Parquet + S3 + DuckDB embebido, pagando centavos de S3 por TB.
En 25 minutos recorremos la arquitectura completa: el índice MySQL particionado como hot tier, Parquet con Hive partitioning en S3 como cold tier, y DuckDB httpfs como engine unificado con predicate pushdown. Demo en vivo de queries analíticas sobre meses de historia: change velocity, historial de columnas, auditoría por fila y cerramos con un DELETE FROM orders; que se revierte en 30 segundos.
Los gotchas reales que descubrimos en producción: DuckDB httpfs no soporta IMDS (tuvimos que escribir un puente de credenciales), schema evolution cuando hubo ALTER TABLE en el medio de la ventana consultada, y el problema feo del FK cascade (hijos borrados que nunca aparecen en el binlog porque nunca tuvieron un UPDATE posterior). Solución: baseline mydumper en Parquet como tercera fuente.
Takeaways:
- El binlog de MySQL es un CDC stream gratis esperando a ser usado - Parquet + S3 + DuckDB como patrón reemplazo de warehouses chicos/medianos - Hive partitioning + predicate pushdown en la práctica - Cuándo "lakehouse casero" alcanza y cuándo necesitás Iceberg/Delta Sobre Daniel Guzmán Burgos: Daniel Guzmán Burgos: creador de dbtrail y bintrail, herramientas open-source para time-travel, analytics y recovery sobre MySQL. Ha hablado en Percona Live, AWS re:Invent y DevBuildConf. Hace 20 años que pelea con MySQL en producción
Watch talk