Postgres 19 Beta tem INSERTs até 30% mais rápidos em benchmark OLTP independente

O ciclo de release anual do 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 → costuma vir com uma dose de ansiedade extra este ano. Segundo o consultor Kaarel Moppel, em post publicado no Planet PostgreSQL, o volume de mudanças no código da versão 19 é visivelmente maior que o normal: um git diff --shortstat contra a v18 mostra 15% mais arquivos alterados, 38% mais inserções e 75% mais remoções de linhas. Houve também uma onda de reverts antes do fechamento das betas, o que tirou um pouco daquela sensação de "vai ser tranquilo como sempre".

Para testar se essa turbulência afetou o que ele chama de "pão com manteiga" do Postgres, o desempenho em cargas OLTP (sistemas transacionais de registro, o tipo de carga que sustenta a maioria das aplicações em produção), Moppel bancou do próprio bolso uma rodada de testes em nuvem. Rodou dois workloads distintos em hardware variado, comparando a v18.6 estável com as Betas 3 e 4 da v19, numa mistura batizada com humor de "versão 3.5".

Como o teste foi montado

O escopo não é pequeno: cerca de 800 horas de execução, equivalentes a 33 dias de runtime acumulado, distribuídas entre instâncias de 4 a 96 vCPUs (incluindo tipos m7gd, m8id, c5d e c7gd) rodando Ubuntu 26.04 Server e Debian 13, dois terços na AWS↳AWS20 conteúdosE-mails de verificação com AWS SES + Lambda (Node.js) e Terraform: do zero ao envioDevSecOps · out 2025Codex na AWS: chegada do agente da OpenAI à nuvem da AmazonDevSecOps · abr 2026Salesforce e AWS ampliam colaboração em IA, CRM e marketplaceDevSecOps · nov 2023Ver tudo em DevSecOps → e um terço na Hetzner. O conjunto de dados foi dimensionado para caber em memória ou exigir pouco acesso a disco, e a medição usou pg_stat_statements para captar o tempo de execução de cada query individualmente.

Foram testadas quatro cargas: leituras por chave (pgbench --select-only), leituras em lote por faixa de aid, atualizações por chave (pgbench --skip-some-updates) e uma variante do teste TPCC adaptada para rodar sobre pgbench, workload que simula um cenário mais realista com mais tabelas e índices.

Alguns detalhes de configuração merecem atenção de quem administra banco de dados de verdade:

• autovacuum foi desabilitado durante os testes, para isolar o efeito puro do motor sem a interferência de vacuum rodando em paralelo;
• o fillfactor do pgbench foi fixado em 80%, simulando um heap que já acumulou "buracos" de uso real, em vez de tabelas recém-criadas e compactadas;
• jit foi mantido desligado, o que já é o comportamento padrão da v19 (mudança de configuração que vale destacar à parte);
• parâmetros como random_page_cost, effective_io_concurrency, wal_compression e track_io_timing receberam ajustes de boas práticas proporcionais ao hardware de cada instância.

Os números: ganho real, mas desigual

No agregado, somando todos os workloads, variáveis de particionamento, protocolo de query e modo de commit (síncrono ou assíncrono), o tempo total de execução dos testes caiu cerca de 3% na v19 em relação à v18.6. É um número modesto, mas positivo, e o próprio Moppel resume o resultado numa frase direta:

Você não deveria se preocupar muito com a capacidade OLTP de dia a dia do PostgreSQL na versão 19!

You shouldn't worry too much about PostgreSQL's bread-and-butter OLTP capabilities with release 19!Kaarel Moppel, consultor e autor do benchmark

O dado mais interessante, porém, aparece quando se olha operação por operação em vez do agregado. A média de melhoria por tipo de statement (SELECT, INSERT, UPDATE) chegou a 7%, mais que o dobro do ganho medido na duração total dos testes. Moppel atribui a diferença a algo que todo DBA que já caçou gargalo sabe: pg_stat_statements mede o tempo de execução da query, mas não captura integralmente o tempo gasto em gerenciamento de sessão, transação e locks. Parte do ganho real pode estar escondida justamente aí.

Por tipo de operação, o quadro ficou assim:

O salto nos INSERTs foi, nas palavras do autor, a única surpresa real do teste, e ele próprio admite que ainda não investigou a causa raiz. Para quem opera cargas de ingestão intensa, como pipelines de eventos, filas persistidas em tabela ou sistemas de auditoria que gravam muito e leem pouco, esse é o número que merece atenção antes de qualquer outro.

O que esse ganho não resolve

As UPDATEs por chave, operação típica de sistemas transacionais clássicos (atualizar saldo, status de pedido, estoque), não acompanharam o ganho. Ficaram estatisticamente empatadas ou levemente piores na v19. Isso é relevante porque é justamente o tipo de carga em que travamento de linha, MVCC e geração de tuplas mortas (o combustível do autovacuum) mais pesam, e é também a carga mais sensível a regressões sutis.

Vale lembrar, e o próprio autor insiste nisso, que autovacuum ficou desligado durante todo o teste. Em produção, UPDATEs repetidas sobre a mesma linha geram bloat de forma constante, e o comportamento do vacuum (que não foi medido aqui) pode pesar tanto ou mais que o ganho ou a perda bruta de cada operação. Um benchmark que isola a variável é metodologicamente correto, mas não substitui o teste da própria carga de trabalho contra o schema real da aplicação.

Ruído de nuvem: o alerta que todo benchmark de VM carrega

Moppel é explícito sobre a dificuldade de medir performance em ambientes de nuvem compartilhada. Ele relata ter visto mais jitter (variação de resultado entre execuções idênticas) do que em testes anteriores, a ponto de descartar outliers e migrar parte dos testes para instâncias "metal" dedicadas e para um segundo provedor (Hetzner), justamente para reduzir a influência de vizinhos ruidosos, NUMA, estados de energia de CPU e cache de sistema operacional.

Para quem for reproduzir esse tipo de teste internamente antes de decidir uma migração, essa é a lição prática: execuções curtas não bastam, e comparar números de uma nuvem pública sem controlar hardware físico pode distorcer a conclusão em qualquer direção.

O que muda para quem administra banco hoje

A v19 ainda está em fase Beta (o teste usa as Betas 3 e 4, sem data de lançamento geral definida), então não há decisão de migração a tomar agora. O valor do material está em outro lugar: é um dos poucos sinais independentes, fora do ciclo oficial de anúncios do projeto, de que o aumento expressivo de mudanças internas na v19 não comprometeu o caminho mais crítico do banco, que é sustentar transações pequenas e frequentes sem degradação.

Para arquiteturas com volume alto de escrita por INSERT, o ganho reportado justifica reservar um ambiente de homologação assim que a v19 sair de Beta para medir o mesmo comportamento contra o schema real, com autovacuum ligado e fillfactor condizente com a tabela de produção. Para cargas dominadas por UPDATE, a recomendação é não esperar ganho automático e tratar a migração como neutra em performance até prova em contrário.

Moppel fecha o post defendendo a retomada do projeto comunitário Postgres Performance Farm, iniciativa que já existiu para publicar automaticamente números de benchmark a cada Beta, hoje inativa. A ausência de um painel assim é, na prática, o motivo pelo qual testes individuais como este continuam sendo a principal fonte de dado concreto sobre performance antes do lançamento oficial.

Fonte: Planet PostgreSQL