Extensão pg_vexec afirma superar ClickHouse em benchmark feito pelo próprio criador

Um mês de trabalho solo contra o motor colunar mais citado do mercado

Exatamente um mês depois de publicar um relato sobre portar o planejador de consultas ORCA do Greenplum para o PostgreSQL↳PostgreSQL11 conteúdosPostgreSQL via SSL com GolangData · abr 20195 itens legais sobre data types do PostgreSQLData · mar 20195 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data → 19, o desenvolvedor Igor Suhorukov voltou ao Planet PostgreSQL com um resultado concreto: o pg_vexec, uma extensão experimental que adiciona execução vetorizada ao banco. Segundo ele, a versão de CPU já roda mais rápido que o ClickHouse em parte do ClickBench, o benchmark público usado para comparar bancos de dados colunares.

O anúncio não é um paper acadêmico nem um release de produto maduro. É o diário de bordo de um projeto individual que, em um mês, saiu de um fork experimental do Greenplum para números que encostam no ClickHouse em sua própria arena. Suhorukov publicou telemetria completa dos testes, um texto explicando a arquitetura e o código-fonte da versão de CPU em três repositórios.

Os números: folga no Parquet, disputa apertada no MergeTree

Os testes rodaram em modo hot run (cache já aquecido, melhor resultado de três tentativas) em um notebook MSI Raider A18 HX A9W, comparando o pg_vexec contra a versão LTS do ClickHouse. O autor usou duas métricas do ClickBench: a média geométrica deslocada (que resume o desempenho nas várias queries sem deixar uma consulta lenta distorcer o total) e o tempo total de execução.

O título do próprio autor resume bem o quadro: à frente no Parquet, perto no MergeTree. No motor nativo do ClickHouse, otimizado a dedo ao longo de anos para ordenação e compressão colunar, a vantagem do pg_vexec é pequena. Já ao ler arquivos Parquet (formato em que o ClickHouse não é o mais afiado do mercado), a diferença salta para uma ordem de grandeza.

De onde vem a vetorização: ORCA, Greenplum e o fork Cloudberry

O PostgreSQL tradicional executa consultas no modelo Volcano: cada operador do plano processa uma tupla por vez, passando-a adiante na árvore de execução. É um desenho elegante e flexível, mas caro em ciclos de CPU quando o volume de dados é grande, porque cada tupla paga o custo de chamadas de função repetidas.

A execução vetorizada ataca esse problema processando blocos de valores de uma mesma coluna por vez, o que aproveita melhor o cache da CPU e instruções SIMD. É o princípio por trás do motor do ClickHouse e também de extensões já conhecidas no ecossistema Postgres, como pg_duckdb (que embute o DuckDB) e o armazenamento colunar do Citus. O pg_vexec entra nesse mesmo território, mas por um caminho diferente: em vez de embutir outro motor, ele deriva do ORCA, o otimizador de consultas em cascata originalmente escrito pela Pivotal para o Greenplum.

O código-fonte da versão de CPU está dividido em três repositórios: o pg_vexec propriamente dito, o pg_ch_table_engines (que reproduz dentro do PostgreSQL o conceito de table engines do ClickHouse, incluindo algo equivalente ao MergeTree) e um branch chamado extension_postgresql_19 no fork do Cloudberry, o projeto comunitário que mantém o legado do Greenplum. É nesse branch que mora a adaptação do ORCA e o conjunto mínimo de patches de core que o PostgreSQL 19 precisa para hospedar tudo isso.

O que um DBA pergunta antes de comemorar um benchmark

Nenhum número de benchmark deveria circular sem o plano de execução por trás dele, e aqui vale o mesmo cuidado. Antes de tratar o resultado como veredito, valem algumas perguntas básicas de quem lida com produção:

• Quem mediu e onde? O teste foi conduzido pelo próprio autor da extensão, em um notebook, sem revisão independente ou reprodução em hardware de servidor.
• O que significa "hot run, melhor de três"? Cache aquecido favorece quem tem footprint de memória mais previsível; não necessariamente reflete carga real de produção com dados frios e concorrência.
• A extensão instala sozinha? Não como um CREATE EXTENSION comum. O projeto depende de um conjunto mínimo de patches no core do PostgreSQL 19, o que o afasta de um binário vanilla.
• A versão testada é a mesma anunciada como futura? A versão de GPU, citada como próximo passo, é descrita pelo próprio autor como rascunho (rough draft), ainda sem números publicados.

Em resumo: os dados são reais e a telemetria está aberta para quem quiser conferir, mas é um benchmark de um homem só, em uma máquina só, numa janela de um mês de desenvolvimento. Isso vale como sinal de que a ideia tem pernas, não como prova de superioridade em produção.

Onde isso mexe em pipelines de dados no Brasil

Muitos times brasileiros hoje mantêm o PostgreSQL como banco transacional e replicam dados para o ClickHouse (ou para um data lake em Parquet consultado por DuckDB ou Trino) só para rodar analytics pesado. Essa separação custa caro: ETL extra, latência entre as duas fontes, duas superfícies de operação e monitoramento, duas linguagens de otimização de query para o time dominar.

Uma extensão vetorizada madura dentro do próprio PostgreSQL atacaria exatamente essa dor, permitindo rodar consultas analíticas pesadas sem tirar os dados do banco transacional. É a mesma promessa que já motiva o pg_duckdb e o armazenamento colunar do Citus, cada um com seu trade-off de maturidade e escopo de queries suportadas. O pg_vexec chega depois, com uma proposta técnica diferente (vetorização derivada do ORCA em vez de embutir outro motor), mas ainda numa fase muito mais embrionária que essas alternativas.

O que falta para sair do laptop e entrar em produção

Para qualquer arquiteto avaliar seriamente o pg_vexec como opção de stack, faltam peças que não aparecem no anúncio: testes em hardware de servidor sob carga concorrente, cobertura do conjunto completo de queries do ClickBench (não apenas um recorte), documentação de quais patches de core seriam necessários e se há caminho para submetê-los à comunidade do PostgreSQL, e alguma garantia de integridade transacional equivalente ao que o motor padrão oferece quando a execução passa a ser vetorizada.

Até lá, o projeto de Suhorukov é um experimento genuinamente interessante de engenharia de banco de dados, publicado com código aberto↳Open source71 conteúdosComo o Open Source Está Liberando o Poder da Automação para TodosDev (Back & Front) · out 2025Código aberto: programadores criam software da NASA sem saberDev (Back & Front) · abr 2021N8N: O que é a ferramenta open source que está revolucionando a automação em TI?Dev (Back & Front) · dez 2025Ver tudo em Dev (Back & Front) → e telemetria verificável. Vale acompanhar os repositórios e o relatório técnico publicado por ele. Mas trocar ClickHouse ou DuckDB por uma extensão de um mês de vida, sem o plano de execução testado no seu próprio ambiente, é decisão que nenhum DBA cuidadoso toma com base só no anúncio.

Fonte: Planet PostgreSQL