Poor man's lakehouse: analytics históricas y recovery sobre MySQL con DuckDB + Parquet

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