PostHog, una plataforma de infraestructura de datos y análisis de productos, anunció recientemente un cambio arquitectónico significativo en su almacén de datos. Después de migrar inicialmente de ClickHouse a DuckDB para resolver problemas de multi-tenencia y obtener acceso a un optimizador de consultas basado en costos, la empresa ahora se está alejando de DuckDB. El movimiento está impulsado por la necesidad de admitir cargas de trabajo más complejas y a gran escala que superaron los límites prácticos de un motor de nodo único en un entorno de nube.

Un gráfico titulado Why we're moving our warehouse off DuckDB
El anuncio de PostHog sobre el cambio arquitectónico fuera de DuckDB.posthog.com

Esta imagen sirve como el recurso visual principal para el tema central del artículo: la transición de una configuración de DuckDB de nodo único a una arquitectura distribuida.

Si bien DuckDB es altamente efectivo para el análisis local y las consultas de nodo único, PostHog descubrió que escalarlo para cargas de trabajo a nivel empresarial presentaba obstáculos significativos. Debido a que DuckDB es una herramienta de nodo único, la empresa tenía que dimensionar las instancias de los trabajadores antes de que llegaran las consultas, un proceso que resultó difícil para predecir los requisitos de CPU y memoria de las consultas impredecibles de los clientes. Además, aunque DuckDB puede volcar datos al disco cuando se agota la memoria, esto resultaba en consultas demasiado lentas y costosas para ser viables para sus usuarios. La empresa también encontró cuellos de botella con la extensión DuckLake, que se utilizaba para mantener la compatibilidad con los formatos estándar de lakehouse. A la escala de PostHog —que incluye aproximadamente 1 billón de filas y 2 petabytes de datos— el esquema de catálogo de DuckLake se convirtió en un cuello de botella, provocando que las escrituras de tablas individuales tardaran más de tres minutos porque cada confirmación requería volver a leer las estadísticas de todo el catálogo.

Para abordar estas limitaciones, PostHog está reconstruyendo su almacén utilizando Trino, un motor de consultas SQL distribuido, combinado con un formato de tabla abierto personalizado llamado HogLake. Este cambio tiene como objetivo proporcionar una arquitectura distribuida que pueda manejar datos a escala de petabytes de manera más predecible que una configuración de nodo único. Además, el movimiento aborda las dificultades de mantener un protocolo Postgres Wire para la compatibilidad con herramientas; PostHog descubrió que gestionar conexiones Postgres de larga duración y los diversos requisitos de varios clientes era más difícil de escalar que utilizar el enrutamiento basado en HTTP. Si bien la nueva arquitectura basada en Trino se está probando actualmente a la escala de PostHog, la empresa aún no ha publicado comparativas de rendimiento específicas para el nuevo sistema en comparación con la implementación anterior de DuckDB.