PostgreSQL 19 chega ao RC1 com REPACK, pg_plan_advice e sincronização de sequências

O primeiro release candidate 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 → 19 ficou disponível em 15 de outubro de 2026. Segundo o cronograma descrito por Tom Kincaid no Planet PostgreSQL, a comunidade planeja um segundo RC em 12 de novembro e a disponibilidade geral (GA) em 19 de novembro, desde que nenhum problema exija nova rodada de correções.

Para quem administra banco de dados em produção, a régua não muda: PostgreSQL 18 continua sendo o alvo de produção até a GA da versão 19 sair. O que muda é a urgência de montar um ambiente de homologação com o RC1 agora, antes que a janela de testes se feche.

Por que tantos recursos saíram pelo caminho

Um número relevante de features anunciadas em betas anteriores foi revertido antes deste RC. Saíram, entre outros, as consultas de grafo em propriedades via SQL, a fusão e divisão de partições, a possibilidade de ligar e desligar checksums de dados com o servidor rodando, o GROUP BY ALL e o UPDATE/DELETE ... FOR PORTION OF.

A justificativa oficial da comunidade, citada por Kincaid, é direta: confiabilidade vem antes, junto com o compromisso de manter um calendário de release previsível. Peter Eisentraut, da EnterpriseDB, descreveu em reflexão recente um conjunto de pressões que se sobrepõem: problemas arquiteturais em algumas features, revisão assistida por IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → encontrando mais casos de borda, e desenvolvedores sênior consumindo tempo em correções de segurança que, em outro cenário, estariam disponíveis para revisar o beta.

Vale separar duas coisas que o relato de Eisentraut distingue com cuidado: a IA acelerando a descoberta de problemas não significa que o código problemático tenha sido escrito por IA. O dado concreto que ilustra esse efeito: o release de manutenção de agosto de 2026 para o PostgreSQL 18 endereçou 28 CVEs, num projeto que historicamente corrigia cerca de duas por ciclo. Revisão mais rigorosa encontra mais falhas, mais rápido — mas isso só ajuda se a capacidade de investigar, corrigir e revisar acompanhar o ritmo.

REPACK: reorganizar tabela sem parar a aplicação (quase)

O novo comando REPACK reescreve uma tabela para recuperar espaço em disco não utilizado e pode reorganizar linhas usando um índice. Com REPACK CONCURRENTLY, leituras e escritas continuam durante a maior parte do trabalho, porque mudanças concorrentes são capturadas via decodificação lógica e aplicadas antes de a operação terminar.

Isso resolve um incômodo real de aplicações com muita atualização, em que o DBA historicamente precisava escolher entre deixar a tabela indisponível ou adiar manutenção que beneficiaria a performance geral. Mas concorrente não é igual a sem bloqueio: a troca final entre tabela antiga e nova ainda exige um lock ACCESS EXCLUSIVE. A operação também consome espaço temporário em disco, e a documentação alerta sobre comportamento de visibilidade para transações que usam snapshots tirados antes do início do repacking.

O desenvolvimento reúne Álvaro Herrera (EDB), Antonin Houska e Mihail Nikalayeu, um exemplo de como a engenharia por trás de um release comunitário atravessa empresas diferentes.

O que testar: escolha uma tabela representativa, com atualizações e exclusões frequentes. Rode o REPACK CONCURRENTLY sob atividade de escrita realista e transações longas em paralelo. Meça espaço recuperado, uso de disco temporário, latência da aplicação durante a operação e, principalmente, a duração do lock final, não apenas se o comando terminou. Dado o volume de revisões que essa feature recebeu, mantenha um plano de rollback pronto.

pg_plan_advice: controle fino, com risco embutido

O PostgreSQL 19 introduz o módulo pg_plan_advice, que permite descrever, reproduzir e restringir decisões específicas do planejador, incluindo ordem de join e método de varredura. Com o módulo carregado, EXPLAIN (PLAN_ADVICE) gera uma string de advice descrevendo essas escolhas; a extensão complementar pg_stash_advice pode armazenar esse advice por identificador de consulta e aplicá-lo automaticamente.

Robert Haas implementou o pg_plan_advice durante sua passagem pela EDB, e a empresa já sinaliza que vai construir recursos adicionais em cima dessa base para ajudar clientes a se recuperar rápido de instabilidade de plano.

É importante não confundir isso com uma chave mágica de performance. O advice restringe o universo de escolhas que o planejador considera: ele não substitui o otimizador nem garante o mesmo plano em toda circunstância. A própria documentação alerta: uma restrição que ajuda hoje pode, conforme os dados mudam, impedir o planejador de escolher uma abordagem melhor amanhã.

O que testar: comece pelas consultas cujos planos já causaram problema no passado. Compare as escolhas normais do planejador com advice aplicado de forma bem direcionada, usando dados e valores de parâmetro representativos do seu workload. Mantenha a intervenção a mais restrita possível e reavalie periodicamente se ela continua útil conforme a carga muda.

Autovacuum com prioridade e paralelismo direcionado

A versão 19 permite que o autovacuum use workers paralelos para a varredura e limpeza de índices, além de introduzir um sistema de pontuação para priorizar trabalho de vacuum e analyze. A view pg_stat_autovacuum_scores expõe essas prioridades.

É paralelismo direcionado, não a promessa de que toda etapa do vacuum agora roda em paralelo. Para quem opera o banco no dia a dia, a pergunta relevante não é quantos workers dá para disparar, e sim se a manutenção consegue acompanhar as tabelas que mais precisam dela, dentro dos recursos disponíveis.

O que testar: combine tabelas movimentadas com atualização constante e tabelas maiores, porém menos ativas. Inspecione as pontuações em pg_stat_autovacuum_scores, observe qual trabalho é priorizado e compare a duração da manutenção com a latência da aplicação e o consumo de recursos. O objetivo é um workload mais saudável, não apenas um subsistema de manutenção mais ocupado.

Replicação lógica: sincronizar sequências, com limites claros

O PostgreSQL 19 adiciona a capacidade de sincronizar valores de sequência do publisher para o subscriber. A sincronização inicial pode ocorrer na criação da subscription, e o comando ALTER SUBSCRIPTION ... REFRESH SEQUENCES ressincroniza sequências já conhecidas depois.

Dois detalhes importam para quem planeja uma migração ou cutover com base nisso:

• O publisher precisa estar rodando PostgreSQL 19 ou mais recente; atualizar só o subscriber não habilita o recurso para um publisher mais antigo.
• Os valores de sequência podem voltar a ficar fora de sincronia conforme o publisher avança a sequência: não é sincronização contínua, e não elimina a necessidade de pensar no procedimento de cutover em si.

O que testar: ensaie a parte de tratamento de sequências do seu procedimento de migração ou cutover de ponta a ponta. Verifique se as definições de sequência batem, se a sincronização de fato completa, e quais valores a aplicação vai gerar depois do corte. Teste o fluxo inteiro, não apenas se o comando roda sem erro.

O que mais merece atenção antes da GA

Essas quatro áreas são ponto de partida, não um checklist completo de upgrade. Mudanças de compatibilidade e de comportamento padrão também pesam: o PostgreSQL 19 desabilita a compilação JIT por padrão, então equipes com workloads analíticos que dependem de JIT para performance precisam avaliar explicitamente essa configuração, em vez de assumir que o comportamento atual se mantém.

Outras adições menores valem registro: ON CONFLICT DO SELECT permite que upserts retornem as linhas já existentes, e funções de janela ganham suporte a IGNORE NULLS.

Vale lembrar que a EDB financia pacotes de teste para a comunidade há mais de 15 anos, incluindo os pacotes RPM e os pacotes do Beta 4 para o PostgreSQL Global Development Group, um lembrete de que a infraestrutura de teste comunitária não aparece sozinha.

O trabalho prático antes de novembro

Um release candidate continua sendo uma versão de teste, não uma recomendação de produção. Monte um ambiente de não-produção que reflita seu deployment real: consultas da aplicação, extensões, drivers, distribuição de dados e rotinas de manutenção. Inclua ensaios de upgrade e recuperação, não apenas demonstrações de feature isolada.

A comunidade se reúne em Valência para o PGConf.EU entre 20 e 23 de outubro, dias depois deste RC1. A pergunta que vale levar para lá, e para dentro de casa, não é só quais features entraram na versão 19. É quais problemas operacionais ela ajuda a resolver, onde as novas capacidades exigem configuração cuidadosa, e o que o seu próprio teste revela antes que alguém descubra em produção.

Fonte: Planet PostgreSQL