PostHog migra 2 PB fuera de DuckDB a su formato HogLake

PostHog movió 2 PB fuera de DuckDB: la letra pequeña de escalar un warehouse

PostHog reconstruyó su warehouse sobre DuckDB hace cinco meses y acaba de desmontarlo: el sistema llegó a alojar cerca de 2 petabytes, alrededor de un billón de filas y 15,3 millones de snapshots antes de que la compañía decidiera reescribir la arquitectura sin DuckDB. Para un founder que está eligiendo stack de datos, la lección no es que DuckDB sea una mala herramienta —el equipo insiste en que sigue siendo fan— sino que lo que funciona impecable en una laptop no se traduce automáticamente a un servicio multiinquilino que corre en la nube.

La compañía lo contó en su propio blog y el texto tiene valor de manual: enumera, con detalle técnico, los cuatro puntos donde una decisión razonable se convierte en una factura y en un cuello de botella.

¿Por qué PostHog dejó ClickHouse para irse a DuckDB?

El punto de partida no fue un capricho técnico. Un clúster compartido de ClickHouse no aguantaba consultas de modelado que duraban horas y no tenía un optimizador de consultas basado en costos. La solución con DuckDB era elegante: cada cliente recibía su propia instancia y herramientas como dbt podían conectarse por Postgres sin fricción.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Funcionó. Hasta que dejó de funcionar.

¿Por qué DuckDB no aguantó en la nube?

DuckDB es, en palabras de PostHog, probablemente la mejor herramienta de un solo nodo para analizar grandes volúmenes de datos. Casi siempre termina la consulta y, si se queda sin memoria, escribe en disco en lugar de morir. Ese diseño, que es una virtud en local, se convierte en un problema operativo cuando hay clientes de por medio.

El motivo central: para correr un motor de un solo nodo de forma segura en la nube hay que dimensionar el worker antes de que llegue la consulta. Y ahí apareció lo que el equipo describe como una ergonomía incómoda: no encontraron una forma razonable de decirle a cada cliente cuántos recursos necesitarían sus consultas, y predecir CPU y memoria para una consulta concreta resultó todavía más difícil.

La salida obvia fue agregar instancias enormes. La otra opción, sumar discos, habría dejado consultas demasiado lentas y caras para ser viables. A eso se sumó otro cuello de botella clásico: traer grandes volúmenes desde S3 sin async fetching, una capacidad que DuckDB incorporó hace relativamente poco.

¿Qué es DuckLake y en qué punto se rompió?

Para usar DuckDB como warehouse completo, PostHog instalaba por defecto la extensión DuckLake, el formato lakehouse de los mismos creadores de DuckDB. La idea de fondo es la misma del motor: mantener las cosas simples y correr en casi cualquier infraestructura.

El problema es de diseño, no de implementación. El esquema del catálogo de DuckLake tiene que mantenerse portable entre muchas bases de datos SQL distintas, y esa portabilidad limita las optimizaciones específicas del motor. A la escala de PostHog, una escritura de una sola tabla podía tardar más de tres minutos, porque cada commit relee las estadísticas de todo el catálogo.

El equipo ajustó con índices de tabla y trucos similares, pero mantener la compatibilidad al 100% con el esquema oficial les dejaba poco margen. Y había un detalle aún más incómodo: más del 99% de las filas de estadísticas del catálogo correspondían a tablas que ya no existían. Limpiarlas aceleró las escrituras entre 30 y 50 veces, pero las filas volvían a crecer.

A eso se suma el número de conexiones que DuckLake abre contra las bases de datos de metadatos, algo que pega fuerte en instancias de Postgres compartidas, donde cada conexión tiene un costo real.

PostHog no empezó pequeño y fue escalando: metió todo PostHog dentro de un DuckLake como primer cliente. Cuando decidieron salir, la cosa pesaba cerca de 2 PB y se rompía de formas difíciles de resolver dentro del alcance del proyecto. Terminaron manteniendo parches en un fork propio, lo que anula justamente el principal beneficio de usar el formato: la comunidad.

El puerto 5432: por qué ofrecer Postgres directo no escala

Una de las promesas más atractivas del producto era que cualquier cliente se conectara por el puerto 5432 con las herramientas que ya usaba. En la práctica, PostHog encontró que escalar eso es mucho más difícil que escalar HTTP.

Los problemas concretos: reconexiones que faltan, gestión de TTLs y de conexiones inactivas a escala, y conexiones de larga duración que salen caras. Además hay muy poco tooling para balancear pgwire comparado con HTTP; la comparación que hacen es la ergonomía de un NLB frente a un ALB de AWS. Con HTTP, las cabeceras permiten enrutar de forma mucho más flexible dentro de Kubernetes.

El otro frente fue el soporte: la lista de clientes de Postgres es interminable y cada uno espera su propio comportamiento. Los clientes pedían arreglos para su librería o su driver particular, y aunque el equipo entregó muchas de esas correcciones, la cobertura nunca llegó a ser suficiente.

¿Qué es HogLake y por qué PostHog apuesta por Trino?

La nueva arquitectura se reconstruyó alrededor de una versión propia de Trino y de un formato de tabla abierto propio, HogLake. La compañía dice que lo está probando primero a escala de petabytes en su propio producto antes de entregarlo a design partners, y que está buscando más socios para testearlo.

La frase que mejor resume el aprendizaje no es técnica: conviene no hypear tanto la tecnología que hay detrás de un warehouse, porque lo que cuenta es la experiencia que entrega.

Qué cambia en el mercado tras la compra de DuckLabs por Amazon

El contexto competitivo se movió al mismo tiempo. GeekWire reportó que Amazon acordó adquirir DuckLabs, la empresa detrás de DuckDB, y que su equipo de más de 30 personas en Ámsterdam se unirá a AWS, incluidos los creadores del motor, Hannes Mühleisen y Mark Raasveldt. El proyecto en sí no se vende: DuckDB sigue bajo licencia MIT y bajo el paraguas de la DuckDB Foundation, igual que DuckLake y Quack, y los términos financieros no se revelaron.

InfoWorld recogió la lectura de Ashish Chaturvedi, de HFS Research, que apunta a un matiz relevante para quien construye encima de estas tecnologías: la licencia no cambia, pero sí la gravedad del proyecto. Según el analista, buena parte del código del núcleo lo escriben ahora personas que cobran de AWS, y eso inclina las prioridades aunque la gobernanza diga otra cosa. El mismo medio consigna que DuckLake 1.0 se lanzó en abril de 2026, y el analista proyecta que lo más probable sea una capa de consulta serverless contra datos en S3 e Iceberg.

MotherDuck, que vende un servicio en la nube sobre DuckDB, anunció soporte empresarial para el motor, algo que había evitado para no competir con DuckLabs, según GeekWire.

¿Qué significa esto para tu startup?

Ninguna de las piezas que fallaron en PostHog es exótica. Son las mismas que aparecen cuando un producto de datos pasa de demo a producción con clientes reales pagando.

Primero, el costo de dimensionar antes de saber. Si tu arquitectura es de un solo nodo por cliente, cada nuevo cliente implica comprometer hardware antes de conocer la forma de sus consultas. Esa asimetría de información es la que termina en instancias sobredimensionadas y márgenes que se evaporan. Instrumenta el consumo de memoria y CPU por consulta y por cliente desde el día uno, no cuando llegue la primera factura incómoda.

Segundo, el formato abierto es una promesa con condiciones. Adoptar un formato abierto te da portabilidad, pero también te ata a su esquema oficial. PostHog podía optimizar solo hasta donde la compatibilidad lo permitía. Antes de comprometerte, pregunta explícitamente qué puedes cambiar del formato y qué no.

Tercero, la ruta de escape es parte del diseño. Vale la pena probar, con tus propios datos, cuánto tarda exportar un snapshot completo a otro motor. Si esa prueba es un proyecto de meses, no tienes portabilidad: tienes una ilusión contractual.

Dos acciones concretas que puedes ejecutar esta semana:

Corre las consultas más pesadas de tus cinco clientes más exigentes con el doble de volumen y mide tres cosas: memoria pico, cuánto se va a disco (spill) y tiempo total. Es la prueba más barata que existe para saber si un motor single-node te aguanta doce meses más.
Si vendes acceso SQL a tus clientes, ofrece además un endpoint HTTP o una API. PostHog lo aprendió con el puerto 5432: la compatibilidad con el cliente de turno es una cola larga que se come el roadmap del equipo.

Conclusión

PostHog no cambió de motor porque DuckDB fuera mala: cambió porque su modelo de negocio exige correr cargas impredecibles de terceros a un precio predecible. Ese es un problema de producto, no de base de datos.

Para un founder, la lectura útil es de método: elige el motor por la forma real de tus consultas, diseña la salida antes de entrar y desconfía de cualquier arquitectura que te obligue a adivinar los recursos del cliente. El resto es hype, y el propio PostHog ya lo dijo: lo que importa es la experiencia.