Postgres 16 vs 17 vs 18: ganhos que importam

As três versões não se distinguem por um único valor de desempenho geral. Cada um corrige um ponto específico da arquitetura, com um público diferente a cada vez: tabelas grandes para Postgres 17, armazenamento de alta latência para Postgres 18. A tabela abaixo resume os fatos verificáveis, todos datados, antes de entrar nos detalhes de cada projeto.

Fontes: notas de lançamento oficiais do projeto PostgreSQL (postgresql.org), com referência cruzada com análises publicadas pela Microsoft Tech Community e Crunchy Data após cada lançamento principal. Acessado em 24 de agosto de 2026.

Antes do Postgres 17, VACUUM armazenava a lista de tuplas mortas para limpar em um array simples, dimensionado por maintenance_work_mem. O problema não era a velocidade do cálculo, mas a estrutura em si: essa tabela estagnava em torno de 1 GB, por mais que fosse configurado além disso. Em uma tabela com mais de 178 milhões de linhas mortas, o VACUUM teve que fazer um loop em várias passagens, cada uma relendo os índices inteiros.

O Postgres 17 substitui esse array por uma estrutura chamada TidStore, uma árvore de raiz adaptativa que comprime fortemente o espaço necessário para armazenar identificadores de tupla. As notas oficiais de lançamento do projeto indicam uma redução de memória utilizada pelo VACUUM em até 20 vezes em alguns casos, sem o teto artificial associado à estrutura antiga. Fonte: Notas de lançamento oficiais do PostgreSQL 17, postgresql.org, 26 de setembro de 2024. A Microsoft Tech Community e a Crunchy Data publicaram, cada uma, uma análise técnica dessa mudança logo após o lançamento. Ambos confirmam o interesse concreto por tabelas com várias centenas de milhões de linhas, com alta taxa de exclusão ou atualização.

Este projeto beneficia principalmente um cenário específico: uma tabela grande com alta taxa de exclusão ou atualização. Anteriormente, o VACUUM era executado em várias passagens devido à falta de memória disponível. Numa mesa pequena, ou numa carga predominantemente de leitura, o ganho permanece marginal, ou mesmo invisível.

O segundo projeto Postgres 17 aborda um ponto mais discreto: o cálculo de instantâneos de transações. Cada consulta precisa saber quais outras transações estão em andamento para impor as regras de visibilidade MVCC do Postgres. Em uma máquina com elevado número de núcleos e conexões ativas, esse cálculo gerou contenção em uma estrutura interna compartilhada. Este é um gargalo documentado há muito tempo pelos colaboradores do projeto.

O Postgres 17 reduz essa contenção. O efeito é medido principalmente em instâncias de alta simultaneidade, com muitas conexões ativas simultâneas em hardware multinúcleo. Numa carga de simultaneidade baixa, a diferença com o Postgres 16 permanece marginal: é um projeto de escalabilidade, não uma redução na latência por solicitação isolada.

Este ganho não substitui um pooler de conexões, simplesmente reduz seu custo interno. Se o número de conexões ativas já é o seu gargalo, a versão principal fica em segundo plano. Nosso guia de ajuste max_connections e nossa comparação de modo de transação PgBouncer exploram esse assunto com mais detalhes.

O Postgres 18, lançado no final de setembro de 2025, aborda um problema mais estrutural. Até então, toda leitura de disco do Postgres bloqueava o processo que a solicitava. O novo subsistema de entrada-saída assíncrona (AIO) permite que um processo inicie múltiplas leituras em paralelo e continue trabalhando enquanto elas são concluídas, em vez de esperar por cada uma delas sequencialmente.

O parâmetro io_method controla este comportamento: worker (processos dedicados a I/O, padrão) ou io_uring no Linux, quando o Postgres foi compilado com este suporte. Varreduras sequenciais, varreduras de heap de bitmap e VACUUM são os primeiros beneficiários, especialmente em armazenamento de alta latência: discos de rede, volumes de nuvem, em vez de NVMe local.

A PlanetScale, que oferece uma oferta gerenciada do Postgres, publicou suas próprias comparações do Postgres 17 vs 18 focadas nesta mudança de E/S. Estas são as medições feitas em sua própria infraestrutura, e não números que reproduzimos aqui de forma independente. Considere isso como um sinal de que vale a pena testar o assunto em sua carga real, não como uma porcentagem universal.

O AIO generalizado do Postgres 18 continua um projeto iniciado no Postgres 17, não uma mudança isolada. A versão 17 já havia introduzido a interface de E/S de streaming, mas limitada a ANALYZE e varreduras sequenciais. O Postgres 18 estende essa mesma lógica para um escopo mais amplo de operações, incluindo VACUUM e varreduras de heap de bitmap. As duas versões, portanto, são lidas como uma progressão, e não como duas apostas separadas em I/O.

Vale a pena monitorar três outras alterações do Postgres 18, mesmo que não abordem diretamente o desempenho bruto.

O ignorar varredura no índice de árvore B de múltiplas colunas permite que o Postgres use um índice composto mesmo quando a consulta não filtra em sua coluna principal. Antes do Postgres 18, esse cenário geralmente exigia uma verificação completa da tabela ou a criação de um índice dedicado adicional.

As colunas virtuais geradas por (GENERATED ALWAYS AS (...) VIRTUAL) tornam-se o comportamento padrão quando STORED não é especificado. Uma coluna virtual é calculada na leitura em vez de ser gravada no disco, o que reduz a quantidade gravada cada vez que a linha de origem é inserida ou atualizada.

O Postgres 18 finalmente adiciona suporte para OAuth 2.0 no lado da autenticação (RFC 8628, fluxo de dispositivo), juntamente com mecanismos existentes como SCRAM, certificados ou LDAP. Um ponto relevante para qualquer organização que já centraliza suas identidades através de um provedor externo OAuth/OIDC.

No Aurabase, o banco de dados de locatários atualmente é executado em Postgres 16.15, não 17. Isso pode ser verificado diretamente no repositório: a imagem CNPG de referência (docker/Postgres.CNPG.Dockerfile) começa em ghcr.io/cloudnative-pg/postgresql:16-standard-bookworm, fixada por digest, a mesma versão principal da camada compartilhada (docker/Postgres.Dockerfile). Verificado em 24 de agosto de 2026.

O código também documenta o porquê. Um comentário de correção em k8s_tenant.rs explica que um substituto anterior apontou erroneamente para postgresql:17.2. O motivo apresentado na época, a imagem padrão não incluiria o pgvector, revelou-se falso após verificação. Ambas as imagens têm pgvector: 0.8.0 em 17.2, 0.8.5 em 16-bookworm padrão medido no cluster da frota.

O risco real, documentado no próprio comentário, está em outro lugar: CloudNativePG proíbe qualquer downgrade de versão principal depois que um cluster for criado. Uma frota provisionada por engano no Postgres 17 seria irreversível, enquanto tudo o que foi validado ponta a ponta no Aurabase estava no Postgres 16.

// Versão principal mantida se TENANT_POSTGRES_IMAGE não estiver definido
let repli = "ghcr.io/cloudnative-pg/postgresql:16-standard-bookworm";

tracing::warn!(
    image = repli,
    "TENANT_POSTGRES_IMAGE non défini : repli sur la version validée."
);

Este não é um julgamento sobre o Postgres 17 como tal. É uma política de prudência operacional: não mudar uma frota de produção para uma versão principal até que a validação de ponta a ponta tenha sido seguida. O mesmo raciocínio se aplica a qualquer equipe que gerencie Postgres via CloudNativePG ou um operador Kubernetes equivalente. A questão não é apenas o ganho de desempenho esperado, mas também o caminho de volta caso algo dê errado.

Você deveria migrar para o Postgres 17 ou 18 agora?

Três critérios permitem decidir sem esperar por um número universal. Primeiro, o tamanho e a taxa de mutação de suas maiores tabelas: se o VACUUM já estiver sendo executado em várias passagens, o local de trabalho de memória do Postgres 17 se aplica diretamente ao seu caso. Então, seu armazenamento: em SSD local de baixa latência, a E/S assíncrona do Postgres 18 fornece menos do que em um volume de rede. Finalmente, o caminho de volta: em uma operadora que proíbe grandes downgrades, testar primeiro em um ambiente descartável não é uma precaução opcional.

Concretamente, a mesma regra se aplica a qualquer frota gerida por um operador Kubernetes. Primeiro provisione um cluster de teste na versão de destino e, em seguida, reproduza nele uma carga representativa de sua produção. Toque no cluster real apenas depois que este teste tiver sido validado de ponta a ponta, e não apenas lendo as notas de versão. Se a sua decisão também diz respeito à escolha entre base dedicada e base compartilhada para absorver esse tipo de mudança, nosso artigo base dedicada vs base compartilhada explora esse ângulo.

A escolha entre Postgres 16, 17 e 18 não se trata apenas de qual versão é “mais rápida”. O Postgres 17 corrige um problema estrutural real de VACUUM em tabelas grandes e reduz a contenção em alta simultaneidade. O Postgres 18 vai além com E/S assíncrona, uma mudança arquitetônica que requer testes em sua carga e armazenamento reais antes de ser generalizada.

O critério mais frequentemente esquecido não é o desempenho, é a reversibilidade. Em uma operadora como CloudNativePG, uma atualização de versão principal não é desfeita após o fato. Antes de mudar uma frota de produção, a verdadeira questão não é apenas o ganho esperado, mas também o caminho de retorno caso o teste falhe. Se você estiver se preparando para esta atualização de versão, nossa Lista de verificação de ajuste do Postgres em produção detalha as configurações para revalidar após uma alteração importante de versão.