As mentiras dos benchmarks de banco de dados

Os benchmarks de banco de dados costumam ser tratados como vereditos finais, mas a realidade é muito mais sutil. O QuestDB demonstra isso ao reexaminar o ClickBench, um dos testes mais respeitados para bancos analíticos. O problema não está no benchmark em si, mas na forma como as métricas são coletadas e interpretadas. Por exemplo, manter um processo ativo entre execuções pode mudar drasticamente os resultados, não por trapaça, mas porque elimina custos ocultos de inicialização como compilação de consulta, cache de metadados Parquet ou aquecimento do buffer pool. Esses fatores estão dentro da medição de tempo, mesmo que a inicialização do processo esteja fora.

Em um cenário com arquivos Parquet, DuckDB e Polars lideram quando cada consulta roda em um processo novo. Mas ao manter o processo vivo, Hyper dispara de último para terceiro lugar com ganho de 2.17x, algo inesperado, já que sua inicialização estava supostamente excluída da contagem. A lição: processos efêmeros escondem custos reais de warmup mesmo dentro do tempo medido. Já o Polars, que já rodava em sessão persistente, não muda seu desempenho, mas perde posição na pontuação geral porque os concorrentes aceleraram. Isso mostra que uma pontuação relativa pode piorar mesmo com desempenho absoluto inalterado.

Para engenheiros de dados e desenvolvedores, esse experimento é um lembrete prático: o desempenho real depende do padrão de uso, não apenas das cifras de um gráfico. Um banco que parece lento em um benchmark com reinícios pode ser rápido em produção, onde conexões persistentes são a norma. Além disso, tecnologias baseadas em JVM, como QuestDB e CrateDB, se beneficiam claramente de mais iterações, seu JIT precisa de tempo para otimizar. Ignorar isso favorece injustamente bancos com compilação estática. A escolha de arquitetura (embedded vs client-server), formato de armazenamento (Parquet externo vs nativo) e até detalhes de configuração (como cache de metadados) impactam diretamente os resultados. Quem toma decisões técnicas precisa questionar o contexto do teste, não só o número final.