PostHog abandona o DuckDB no produto de warehouse e migra para o Trino

A PostHog explica que reconstruiu o produto de warehouse sobre o DuckDB há cinco meses porque um cluster ClickHouse compartilhado não aguentava consultas de modelagem de várias horas e não tinha otimizador de consultas baseado em custo. O DuckDB deu a cada cliente uma instância própria e permitiu que ferramentas como dbt se conectassem via Postgres. O problema veio com a escala: os clientes rodaram consultas mais complexas do que o previsto, e a empresa teve de adotar instâncias enormes. Como o motor é de nó único, o worker precisa ser dimensionado antes da chegada da query, e prever CPU e memória de uma consulta específica se mostrou muito difícil.

O DuckLake, formato de lakehouse instalado por padrão, trouxe outro gargalo. O esquema do catálogo precisa ser portátil entre vários bancos SQL, o que limita otimizações específicas. Em uma escrita em uma única tabela, o tempo passava de três minutos porque cada commit relia as estatísticas do catálogo inteiro. Mais de 99% das linhas de estatísticas pertenciam a tabelas que já não existiam. A limpeza deixou as escritas de 30 a 50 vezes mais rápidas, mas as linhas voltavam a crescer. Ao sair, o lake tinha cerca de 2 PB, 1 trilhão de linhas e 15,3 milhões de snapshots. Sem conseguir emplacar mudanças na comunidade na velocidade necessária, a empresa passou a manter patches em um fork.

O acesso direto por Postgres (porta 5432) também pesou. Reconexões, TTLs e conexões ociosas são difíceis de gerenciar em escala, há pouca ferramenta de balanceamento para pgwire em comparação com HTTP, e cada cliente Postgres espera comportamentos próprios. A nova versão usa uma variante própria do Trino e um formato de tabela aberto, o HogLake, testado primeiro no volume de petabytes da própria PostHog antes de ir para design partners.

Para quem opera analytics em nuvem, o caso é um aviso sobre a diferença entre uma ferramenta excelente em uma máquina e uma plataforma multiusuário. Na leitura do CEVIU, a dor central foi previsibilidade de recursos e custo do catálogo de metadados, mais do que velocidade bruta de consulta. Vale medir esses dois pontos antes de escolher motor e formato de tabela, principalmente se o plano inclui trilhões de linhas.