A cada nova versão principal do PostgreSQL, acompanhar as funcionalidades anunciadas é apenas uma parte do trabalho. Para quem administra bancos de dados, também é importante entender como esses recursos evoluem durante o desenvolvimento, quais problemas são identificados nos testes e o que precisa ser validado antes de considerar uma atualização.
Esse acompanhamento ganha importância com o PostgreSQL 19. Em outubro de 2026, o projeto disponibilizou o primeiro Release Candidate (RC 1), uma versão candidata a lançamento que sucede o período de testes beta e se aproxima da versão final.
O anúncio também trouxe uma lista de correções aplicadas desde o Beta 4, publicado em setembro. Os ajustes envolvem recursos de manutenção, planejamento de consultas, replicação lógica, processamento paralelo e exportação de dados.
Mas o que essas mudanças significam para quem trabalha com PostgreSQL? E o que ainda pode mudar antes da disponibilização geral da versão 19?
O que significa chegar ao Release Candidate?
O ciclo de desenvolvimento de uma nova versão principal do Postgres passa por etapas de desenvolvimento, testes beta e versões candidatas ao lançamento.
Durante a fase beta, os recursos são disponibilizados para que a comunidade teste as funcionalidades previstas, identifique problemas e contribua para o amadurecimento da versão. É também uma etapa em que mudanças mais significativas ainda podem ocorrer, inclusive a retirada de funcionalidades que não estejam suficientemente maduras.
O Beta 4, publicado em 24 de setembro, exemplifica esse processo. Na ocasião, o projeto retirou recursos que precisavam de mais tempo de desenvolvimento e revisão, como o suporte a consultas de grafos SQL/PGQ e comandos específicos para divisão e combinação de partições.
A decisão reforça um princípio importante do projeto: a confiabilidade da versão tem prioridade sobre a inclusão de funcionalidades a qualquer custo.
Com o RC 1, o cenário muda. As versões beta e candidatas a lançamento são consideradas versões com funcionalidades congeladas (feature freeze), ou seja, não é esperado que novos recursos sejam acrescentados. O foco passa a ser a identificação e a correção de problemas antes da disponibilização geral.
Isso não significa que o código esteja livre de defeitos ou que todas as mudanças estejam definitivamente encerradas. Uma versão candidata deve ser muito próxima da versão final, mas correções adicionais e até uma nova candidata podem ser necessárias.
Para DBAs, desenvolvedores e equipes responsáveis por plataformas de dados, esse é um momento oportuno para começar a testar compatibilidade e comportamento com cargas de trabalho representativas, sempre em ambientes que não sejam de produção.
Fonte: anúncio do PostgreSQL 19 Beta 4 e informações oficiais sobre testes beta.
O que mudou do Beta 4 para o RC 1?
De acordo com o anúncio oficial de outubro/2026, as correções aplicadas desde o Beta 4 abrangem diferentes áreas do PostgreSQL 19. Embora não representem necessariamente novas funcionalidades, elas ajudam a entender quais aspectos estão sendo refinados antes do lançamento.
1. REPACK: correções em um novo recurso de manutenção
Uma das novidades previstas para o PostgreSQL 19 é o comando REPACK, que unifica operações de reorganização de tabelas anteriormente associadas a comandos como VACUUM FULL e CLUSTER.
A reorganização pode ajudar a recuperar espaço em disco e melhorar a disposição física dos dados. Já a opção REPACK (CONCURRENTLY) permite manter leituras e escritas durante a maior parte da reorganização, reduzindo o impacto sobre a disponibilidade da aplicação. Entretanto, a etapa final exige um bloqueio exclusivo para substituir os arquivos da tabela e dos índices, interrompendo temporariamente esses acessos. Por isso, a execução ainda precisa ser planejada, especialmente em tabelas com grande volume de alterações concorrentes.
Desde o Beta 4, o projeto aplicou diversas correções nesse recurso.
Para quem administra bancos de dados, isso é um lembrete de que funcionalidades relacionadas à manutenção precisam ser avaliadas não apenas pela sua proposta, mas também pelo comportamento em diferentes condições de execução.
Em testes, vale observar a duração da operação, o consumo de recursos, o espaço necessário, os efeitos sobre a concorrência e o comportamento em tabelas representativas do ambiente. Também é importante verificar as limitações e os requisitos descritos na documentação da versão.
A existência de uma opção concorrente não elimina a necessidade de planejar a operação nem garante o mesmo resultado em todos os cenários.
2. Planejador de consultas: ajustes nas otimizações e no pg_plan_advice
O PostgreSQL 19 inclui melhorias no planejador de consultas, além do módulo pg_plan_advice, desenvolvido para permitir maior controle sobre as decisões de planejamento.
O planejador avalia diferentes estratégias para executar uma consulta e escolhe um plano com base em fatores como estatísticas, estimativas de cardinalidade e custos previstos. Pequenas diferenças nessas estimativas podem levar a estratégias de execução distintas.
Entre as correções publicadas no RC 1 estão ajustes em pg_plan_advice e em novas otimizações que dependem da possibilidade de uma expressão retornar NULL.
Esse último ponto é importante porque o tratamento de valores nulos interfere na lógica de diversas expressões SQL. Uma otimização só pode ser aplicada quando suas condições são respeitadas; caso contrário, existe o risco de alterar o resultado esperado de uma consulta.
Para DBAs e profissionais de performance, o caminho é comparar planos de execução, resultados e tempos de resposta em consultas representativas. Também vale verificar se as otimizações continuam produzindo resultados corretos diante de diferentes distribuições de dados e condições de consulta.
O objetivo não é presumir que uma nova versão tornará todas as consultas mais rápidas, mas identificar quais cargas de trabalho podem se beneficiar das mudanças e onde será necessário investigar diferenças de comportamento.
3. Replicação lógica: correções na habilitação automática
O PostgreSQL 19 prevê uma mudança relacionada à configuração da replicação lógica. Com wal_level definido como replica, o servidor poderá habilitar automaticamente a replicação lógica quando necessário, sem exigir uma reinicialização apenas para alterar esse nível de configuração.
O RC 1 inclui correções no mecanismo que habilita automaticamente o nível de WAL necessário à replicação lógica quando wal_level está configurado como replica. Nesse cenário, o valor configurado permanece inalterado, enquanto effective_wal_level indica o nível efetivamente utilizado.
O recurso pode simplificar determinados cenários de configuração, mas não elimina a necessidade de compreender os requisitos da replicação lógica. A topologia utilizada, as permissões, as publicações e assinaturas, a sincronização inicial e a capacidade de processamento continuam sendo aspectos importantes do planejamento.
Nos testes, vale verificar como a configuração se comporta nos cenários previstos para o ambiente, incluindo a criação e o gerenciamento de publicações e assinaturas, a sincronização de dados e a recuperação após interrupções.
A documentação da versão também apresenta outros avanços na replicação lógica, como a replicação de valores de sequências. São mudanças que merecem avaliação conjunta quando a arquitetura depende desse mecanismo para integração de dados ou distribuição de cargas de trabalho.
4. Autovacuum paralelo: correções no processamento de índices
Outra área contemplada pelas correções do RC 1 é o autovacuum paralelo.
O RC 1 recebeu diversas correções no autovacuum paralelo, recurso do PostgreSQL 19 que distribui entre processos o trabalho de remoção de entradas mortas e limpeza dos índices elegíveis, sem paralelizar a varredura da tabela. O recurso é controlado por autovacuum_max_parallel_workers, desabilitado por padrão, e também depende da disponibilidade de processos dentro do limite de max_parallel_workers.
Esses mecanismos têm relação direta com a administração de ambientes que acumulam grandes volumes de dados e precisam equilibrar manutenção, desempenho e disponibilidade.
A introdução do processamento paralelo, porém, também torna importante avaliar o consumo de recursos e a concorrência com as cargas de trabalho da aplicação. O ganho potencial depende das características das tabelas, dos índices, da configuração e dos recursos disponíveis.
Ao testar a nova versão, é interessante acompanhar a execução das rotinas de manutenção, o uso de CPU e I/O, a duração das operações e o comportamento de consultas concorrentes. Também vale verificar como as novas opções de configuração interagem com os limites já definidos para o ambiente.
As correções aplicadas antes do lançamento mostram que esse tipo de recurso precisa ser validado em diferentes cenários para que possa ser utilizado de forma previsível.
5. COPY com saída JSON: correção nos nomes das chaves
O comando COPY também recebeu uma correção específica.
O PostgreSQL 19 acrescenta a possibilidade de exportar dados em formato JSON com COPY TO. No RC 1, o projeto corrigiu o comportamento de COPY (query) TO … (FORMAT json) para que as chaves do JSON utilizem os nomes das colunas da consulta, incluindo aliases, em vez dos nomes das colunas originais das tabelas.
A diferença pode ser importante para processos de integração, exportação e transformação de dados, nos quais a estrutura de saída precisa corresponder ao formato esperado por outro sistema.
Por exemplo, quando uma consulta utiliza um alias para renomear uma coluna, o nome apresentado no JSON deve respeitar o resultado da consulta. Caso contrário, a estrutura exportada pode não corresponder ao contrato esperado pela aplicação que consome os dados.
Para quem utiliza o COPY em rotinas de integração, vale testar exportações com aliases, nomes de colunas repetidos ou outras situações relevantes para a aplicação, além de verificar o formato efetivamente produzido.
E as estatísticas do postgres_fdw?
O RC 1 também corrigiu a importação de estatísticas pelo postgres_fdw. A operação passa a ser executada como o proprietário da tabela estrangeira, em vez de utilizar o usuário que executa o comando ANALYZE.
Esse ajuste é relevante para ambientes que consultam dados remotos por meio do Foreign Data Wrapper do PostgreSQL. Neles, as estatísticas podem contribuir para que o planejador escolha estratégias de execução mais adequadas.
Se o ambiente utiliza postgres_fdw, vale incluir esse cenário nos testes, especialmente quando diferentes usuários e proprietários de objetos participam das rotinas de manutenção e análise.
Em conjunto, essas correções mostram que a estabilização de uma versão envolve tanto recursos novos quanto detalhes de execução, permissões e comportamento que podem afetar operações existentes.
A lista acima reúne os destaques do anúncio oficial, não todas as alterações do RC 1. A relação completa está disponível na página oficial da versão candidata.
O que ainda pode mudar antes do lançamento final?
O anúncio do RC 1 estabelece as próximas etapas do calendário de lançamento do PostgreSQL 19.
| Data planejada | Etapa | O que acompanhar |
| 12 de novembro de 2026 | PostgreSQL 19 RC 2 | Novas correções e eventuais ajustes identificados durante a validação. |
| 19 de novembro de 2026 | Disponibilização geral (GA) | Publicação da versão final, caso não seja necessário adiar o lançamento ou gerar outra candidata. |
O RC 2 foi planejado para 12 de novembro, na mesma data da próxima atualização das versões suportadas do PostgreSQL. Segundo o projeto, essa atualização incluirá um conjunto significativo de correções, que também serão incorporadas ao PostgreSQL 19 antes da disponibilização geral.
A data planejada para o lançamento final é 19 de novembro. No entanto, o calendário depende da avaliação dos problemas encontrados durante os testes. Se for identificada uma questão que exija mais tempo de correção, o projeto poderá adiar o lançamento ou publicar uma candidata adicional.
É importante interpretar esse calendário corretamente. As datas indicam o planejamento oficial disponível no momento, não uma garantia de que a versão final será necessariamente publicada naquele dia.
Também não se espera que o RC 2 seja uma versão com um novo conjunto de funcionalidades. Como a etapa é voltada à estabilização, o foco deve continuar nas correções e na validação do comportamento da versão.
Para acompanhar essas mudanças, a referência mais confiável é o site oficial do PostgreSQL, em conjunto com as notas de lançamento da versão 19.
Como o DBA pode se preparar para o PostgreSQL 19?
A fase de Release Candidate oferece uma oportunidade para conhecer as mudanças antes da versão final, sem precisar esperar o lançamento para começar a avaliar seus possíveis impactos.
O primeiro passo é identificar quais recursos novos têm relação com o ambiente administrado. Nem todas as mudanças serão relevantes para todas as instalações. Um ambiente que utiliza intensivamente replicação lógica, por exemplo, terá prioridades de teste diferentes de outro em que a maior preocupação está na manutenção de tabelas ou na performance de consultas.
A partir disso, alguns cuidados ajudam a organizar a avaliação:
- Revisar as mudanças documentadas: Leia as notas de lançamento e identifique funcionalidades, alterações de comportamento e incompatibilidades que possam afetar a instalação. Dê atenção especial às extensões e ferramentas das quais o ambiente depende.
- Preparar um ambiente de testes representativo: Utilize uma instalação isolada, com dados de teste e configurações próximas das utilizadas na operação. Quando possível, reproduza consultas, rotinas de manutenção e integrações que sejam importantes para o negócio.
- Validar aplicações e extensões: Confira se os componentes utilizados são compatíveis com a nova versão e teste os fluxos mais críticos. A compatibilidade não deve ser presumida apenas porque a aplicação já funciona em uma versão anterior.
- Comparar desempenho e comportamento: Registre resultados de consultas, consumo de recursos e duração de operações relevantes. Uma comparação útil precisa considerar condições de teste equivalentes e observar tanto possíveis ganhos quanto regressões.
- Planejar a atualização: Antes de definir uma data para migração, avalie os requisitos de atualização de versão principal, a estratégia de backup e restauração, a janela de manutenção, as dependências e o plano de reversão.
O PostgreSQL 19 RC 1 não deve ser utilizado em produção. A recomendação do projeto é reservar versões beta e candidatas a lançamento para testes. Para migrar uma instalação anterior, será necessário utilizar uma estratégia apropriada de atualização de versão principal, como pg_upgrade, pg_dump e pg_restore, ou replicação lógica, conforme o cenário.
Mais informações estão disponíveis na documentação oficial sobre atualização para o PostgreSQL 19.
Acompanhar o desenvolvimento também faz parte da administração
A chegada do PostgreSQL 19 RC 1 representa mais do que uma nova data no calendário. Ela marca a transição para uma etapa em que a atenção se concentra na confiabilidade, na compatibilidade e na correção dos detalhes que podem fazer diferença em ambientes reais.
As mudanças publicadas desde o Beta 4 envolvem manutenção, otimização de consultas, replicação e integração de dados. Para quem administra bancos, conhecê-las ajuda a identificar o que merece ser testado e quais aspectos podem exigir planejamento antes de uma futura atualização.
Até o lançamento final, previsto para 19 de novembro de 2026, o acompanhamento das versões candidatas e das notas oficiais permite atualizar essa avaliação conforme novas informações forem publicadas.
A melhor preparação não consiste em atualizar o ambiente assim que uma nova versão é disponibilizada, mas em entender o que mudou, avaliar o que se aplica ao cenário administrado e reunir evidências suficientes para tomar uma decisão consciente.
Receba mais conteúdos como este!
Assine a nossa newsletter e acompanhe conteúdos técnicos, análises e discussões sobre PostgreSQL, arquitetura e engenharia de dados.