Hace cinco meses, PostHog reconstruyó su data warehouse sobre DuckDB. Ahora Benjamin Knofe-Vider explica en Why we’re moving our warehouse off DuckDB por qué lo están dejando. Me ha llamado la atención por dos motivos: porque hace un par de semanas escribía sobre DuckDB 2.0, y porque no es el típico artículo de “esta herramienta no sirve”. Al contrario, empieza diciendo que siguen siendo fans.
Lo que cuenta es más interesante que una crítica: dónde están los límites de un motor pensado para una sola máquina cuando lo conviertes en un servicio en la nube para miles de clientes.
Por qué eligieron DuckDB
El punto de partida era ClickHouse. Un clúster de ClickHouse compartido no aguantaba bien las consultas de modelado de datos que duran horas, y además le faltaba un optimizador de consultas basado en costes. DuckDB les permitía dar una instancia a cada cliente, y herramientas como dbt podían conectarse hablando el protocolo de Postgres. Sobre el papel, encajaba muy bien.
Un solo nodo es una virtud… hasta que no lo es
Knofe-Vider dice que DuckDB es probablemente la mejor herramienta de un solo nodo para analizar montañas de datos, y que ese nodo puede ser tu portátil. Casi siempre termina la consulta, y si se queda sin memoria, vuelca a disco.
El problema es que eso mismo, en la nube, se vuelve en contra. Los clientes lanzaban consultas más complejas de lo que esperaban, así que tuvieron que poner instancias enormes. Añadir disco era posible, pero las consultas serían demasiado lentas y caras.
Y aquí está la clave del artículo: para ejecutar un motor de un solo nodo de forma segura en la nube, hay que dimensionar la máquina antes de que llegue la consulta. No encontraron una forma razonable de decirle a un cliente qué recursos iba a necesitar su consulta, y predecir CPU y memoria para una consulta concreta era todavía más difícil. Un motor distribuido reparte el trabajo cuando la consulta ya ha llegado; uno de un solo nodo te obliga a acertar de antemano.
También mencionan la lectura de datos desde S3 sin peticiones asíncronas, algo que DuckDB “sólo ha añadido recientemente”. Se refieren a la E/S asíncrona de DuckDB 2.0, precisamente la mejora que a mí más me interesaba de esa versión. Les ha llegado tarde.
DuckLake a un billón de filas
Para usar DuckDB como warehouse completo instalaron por defecto DuckLake, el formato lakehouse de los mismos creadores. Y lo probaron a lo grande: metieron todo PostHog en DuckLake, como primer cliente de su propio producto. Cuando lo dejaron, guardaba unos 2 PB, cerca de un billón de filas y 15,3 millones de snapshots.
DuckLake sigue la filosofía de DuckDB: ser simple y funcionar casi en cualquier sitio. Su catálogo tiene que poder vivir en muchas bases de datos SQL distintas, y esa portabilidad limita las optimizaciones específicas de cada motor. Los problemas que describen son muy concretos:
| Problema | Efecto |
|---|---|
| Cada commit volvía a leer las estadísticas de todo el catálogo | Una escritura en una sola tabla podía tardar más de 3 minutos |
| Más del 99% de las filas de estadísticas eran de tablas ya borradas | Al limpiarlas, las escrituras iban de 30 a 50 veces más rápido, pero volvían a crecer |
| Muchas conexiones abiertas a la base de datos de metadatos | Caro en instancias de Postgres compartidas |
Añadieron índices y otros ajustes, pero para seguir ofreciendo DuckLake tenían que mantener la compatibilidad total con el esquema oficial, lo que les dejaba poco margen. Y como no podían incorporar cambios al proyecto tan rápido como los necesitaban, acabaron manteniendo parches en un fork. Lo dicen ellos mismos: eso elimina una de las grandes ventajas de usar DuckLake, que es la comunidad.
Hablar Postgres es más difícil de lo que parece
La parte que más me ha sorprendido es la del protocolo. Ofrecer conexiones directas de Postgres por el puerto 5432 suena muy bien: cualquier cliente, cualquier herramienta de BI, cualquier librería se conecta sin más. En la práctica, les costó mucho más escalar que HTTP:
- Gestionar reconexiones, TTL y conexiones inactivas a gran escala es complicado, y las conexiones largas son caras.
- Hay muy pocas herramientas para balancear carga del protocolo de Postgres (pgwire) comparadas con HTTP. Ponen como ejemplo la diferencia entre un NLB y un ALB de AWS.
- Las cabeceras HTTP hacen el enrutado en Kubernetes mucho más flexible.
- Y hay una lista interminable de clientes de Postgres, cada uno con sus manías. Los clientes les pedían que arreglaran su cliente o su librería concretos, y por muchos arreglos que hicieron, nunca llegaron a una cobertura suficiente.
Es algo que conviene recordar cada vez que un producto presume de ser “compatible con Postgres”. Ser compatible con el protocolo es una cosa; ser compatible con todo lo que los clientes reales esperan de Postgres es otra muy distinta.
Lo que viene: Trino y HogLake
Han reconstruido todo sobre su propia variante de Trino, un motor de consultas distribuido, y han creado su propio formato de tabla abierto, HogLake. Lo están probando primero con los datos del propio PostHog, a escala de petabytes, antes de dárselo a los primeros clientes.
Me gusta que el propio artículo diga que han aprendido a no dar tanto bombo a la tecnología que hay detrás de un warehouse, y que lo que cuenta es la experiencia que da. Viniendo de quien hace cinco meses anunciaba el cambio a DuckDB, es una lección aplicada a sí mismos.
Lo que me llevo
No leo esto como un fracaso de DuckDB. Leo que DuckDB es excelente para lo que está pensado, una máquina y una persona o un proceso analizando datos, y que convertirlo en un warehouse multiinquilino en la nube es otro problema. Como contaba a raíz de la compra de DuckLabs por AWS, en CARTO también usamos DuckDB, así que este tipo de experiencias en producción me interesan especialmente. El modo servidor de la 2.0 va en la dirección de la nube, pero lo de PostHog muestra que es sólo una pieza: falta saber cómo dimensionar, cómo repartir y cómo escalar un catálogo.
Y de paso, dos ideas que sirven más allá de DuckDB. Un motor de un solo nodo obliga a acertar con los recursos antes de ejecutar, y eso en un servicio multiinquilino es muy difícil. Y la compatibilidad con Postgres tiene una cola larga que no aparece en las demos y que cuesta mucho cubrir.
Fuente: Why we’re moving our warehouse off DuckDB, Benjamin Knofe-Vider, PostHog.
