Moviendo nuestro warehouse fuera de DuckDB
Las frecuentes migraciones de bases de datos y warehouse en la empresa de analítica PostHog están generando preguntas sobre planificación, pruebas de escalabilidad y la influencia de reescrituras “fáciles” impulsadas por LLM en las decisiones de ingeniería. Los comentaristas debaten los méritos de DuckDB, ClickHouse, Trino y los formatos de data lake/tablas para cargas multi-tenant y a gran escala, mientras critican la falta de datos concretos de rendimiento y de una justificación técnica clara en la publicación del blog de PostHog sobre dejar DuckDB. Muchos ven la rápida rotación del stack como sintomática de un desarrollo impulsado por el currículum y de una débil disciplina arquitectónica, más que de una evolución cuidadosamente medida.
Aclaraciones sobre el alcance y la arquitectura
- El cambio concierne a un producto de warehouse ofrecido a clientes, no a la base de datos principal de analítica.
- ClickHouse sigue impulsando la analítica central; DuckDB se usaba para una oferta de warehouse separada y piloto para un pequeño número de clientes.
- El nuevo diseño es un motor de consultas distribuido basado en Trino sobre un formato de tablas personalizado (“HogLake”), pensado principalmente para modelado y ETL de larga duración, no para consultas de baja latencia.
Experiencia con DuckDB y límites de escalado
- DuckDB funcionó correctamente, pero requirió pods muy grandes (del orden de ~46 vCPU y cientos de GB de RAM) para manejar consultas reales de clientes, algunas de más de 12 horas.
- Bajo carga multi-tenant (muchas consultas pesadas del mismo cliente), esto se volvió económicamente inviable.
- Estimar el uso de CPU/memoria por consulta resultó difícil. Se señaló que un protocolo cliente/servidor de DuckDB (Quack) no admite consultas distribuidas reales.
Razones para Trino + una arquitectura tipo lake
- Trino se ve como una opción que ofrece una asignación de recursos más flexible y distribuida, mejor adaptada a cargas de trabajo intensas y con picos.
- DuckDB es elogiado como un excelente motor de un solo nodo, pero se considera una mala adaptación para este contexto en la nube y multi-tenant.
- Se evaluaron Iceberg/Delta, pero se rechazaron por escrituras lentas y otras desventajas para este caso de uso.
Críticas: planificación, cambios constantes y metodología
- Muchos comentaristas ven el cambio de ClickHouse → DuckDB → Trino/HogLake en pocos meses como mala planificación o “churn”, con pruebas de escala insuficientes de antemano.
- Algunos lo enmarcan como desarrollo impulsado por el currículum o por agentes/LLM, cambiando tecnologías en lugar de ajustar profundamente una sola.
- Otros defienden la experimentación, argumentando que el comportamiento real a escala suele emerger solo bajo cargas orgánicas.
Deseo de más profundidad técnica y participación de la comunidad
- Varios comentaristas querían métricas concretas, modos de fallo y metodología para la predicción y pruebas de capacidad, además de una explicación más clara de por qué era necesario un formato personalizado.
- Algunos sostienen que mantener forks y devolver mejoras al upstream es normal a escala y querían más detalles sobre parches y colaboración.
- Sigue sin quedar claro, a partir de la discusión, si la nueva configuración con Trino/HogLake ha resuelto definitivamente los problemas originales.
Reacciones varias
- Algunos critican el estilo del blog de marketing de la empresa y el diseño del sitio web; otros lo encuentran distintivo o atractivo.
- Otros temas más amplios que surgieron incluyen la dificultad de elegir bases de datos sin experiencia profunda, fallos de los líderes al detectar patrones, y el riesgo de reescrituras fundamentales frecuentes.