PostgreSQL 18: detalhes do lançamento e novidades do PostgreSQL 19 Beta

O PostgreSQL 18, lançado oficialmente em 25 de setembro de 2025, representa um marco técnico com avanços estruturais reais: o novo subsistema de I/O assíncrono (AIO) — suportando tanto io_uring quanto modo worker — entrega ganhos de até 3x em leituras sequenciais e VACUUM em ambientes Linux modernos, especialmente em nuvem. A ativação padrão de checksums de página via initdb com CRC32C impõe verificação contínua de integridade de dados, exigindo migrações explícitas com --no-data-checksums para clusters anteriores. O PostgreSQL 18 também traz colunas geradas virtuais habilitadas por padrão, uuidv7() para UUIDs ordenados, skip scan em índices B-tree, autenticação OAuth 2.0, depreciação definitiva do MD5 para senhas (recomendando SCRAM-SHA-256), e a primeira atualização do protocolo de comunicação desde 2003: a versão 3.2 do protocolo PostgreSQL, com suporte a chaves de cancelamento de 256 bits.

O PostgreSQL 19 Beta 1, disponibilizado em 4 de junho de 2026, já está estável o suficiente para testes em staging e prepara o lançamento geral previsto para setembro/outubro de 2026. Ele aprimora o AIO com escalabilidade dinâmica (io_min_workers e io_max_workers), introduz REPACK CONCURRENTLY, SQL/PGQ para consultas de grafos, suporte completo a UPDATE e DELETE com FOR PORTION OF (temporal tables), e resolve o problema crítico de estouro de MultiXact com transição para membros de 64 bits — eliminando o cenário 'vacuum or die'. Também inclui pg_plan_advice para controle granular do planejador e compactação TOAST padrão em lz4.

Essas mudanças impactam diretamente a confiabilidade, escalabilidade e custo operacional de aplicações críticas: o PostgreSQL 18 reduz riscos de corrupção silenciosa com checksums ativados por padrão e acelera atualizações principais graças ao pg_upgrade que preserva estatísticas do otimizador — evitando degradação pós-migração. Para equipes de desenvolvimento, uuidv7() e colunas geradas virtuais simplificam arquiteturas sem necessidade de triggers ou views materializadas. Já o PostgreSQL 19 Beta 1 antecipa soluções para gargalos de produção reais, como o REPACK CONCURRENTLY (que substitui abordagens externas como pg_repack) e o suporte a SQL/PGQ, posicionando o PostgreSQL como alternativa viável a bancos especializados em grafos — tudo sem sair do ecossistema SQL padrão.

Desenvolvedores precisam adaptar códigos e pipelines para aproveitar as novidades do PostgreSQL 18: migrar de MD5 para SCRAM nas conexões, ajustar queries para usar skip scan em índices compostos e validar compatibilidade com o novo comportamento de RETURNING (acesso a OLD e NEW). Em projetos novos, adotar uuidv7() passa a ser recomendado para melhor desempenho de indexação. No PostgreSQL 19 Beta 1, é essencial testar o uso de FOR PORTION OF em aplicações temporais e avaliar o pg_plan_advice para otimizações de performance sensíveis a planos incorretos. A mudança para lz4 como compactação TOAST exige revisão de configurações de armazenamento e monitoramento de uso de CPU em cargas pesadas de escrita.