PostgreSQL 19 Beta 2: teste agora para não improvisar no upgrade final
A segunda beta foi publicada em 16 de julho com correções em vacuumdb, tabelas temporais, logical decoding, SQL/PGQ, autovacuum e outras áreas. O próprio projeto desaconselha beta em produção. O uso certo é construir uma repetição fiel, comparável e reversível.
- Natureza
- Plano operacional de avaliação de pré-lançamento
- Ambiente
- Cópia isolada sem dados pessoais desnecessários e sem tráfego de produção
- Publicado e verificado
- 6 de agosto de 2026
- Limite
- Aprovação final depende da versão GA, release notes finais e suporte das extensões/fornecedores usados
Em resumo
A Beta 2 contém pré-visualizações e pode mudar antes da disponibilidade geral, prevista pelo projeto para setembro ou outubro de 2026. Uma avaliação útil restaura dados saneados ou sintéticos, instala as extensões reais, executa pg_upgrade --check, testes de aplicação, consultas críticas, backup/restore, replicação e rollback. O resultado não é aprovar PostgreSQL 19 hoje; é produzir uma lista de incompatibilidades, tempos, donos e critérios que reduzam risco quando a versão final e as extensões suportadas existirem.
- PostgreSQL 19 Beta 2 é uma versão de teste e o projeto desaconselha produção e desenvolvimento ativo.
- Mudanças de comportamento e APIs ainda podem ocorrer; medições da beta não são promessa para a versão final.
- Teste schemas, extensões, drivers, replicação, backup/restore, desempenho e operação — não apenas arranque do servidor.
- Não escolha link mode sem compreender o efeito no rollback; pg_upgrade documenta diferenças entre copy, clone, link e swap.
A pergunta certa não é se a beta arranca
A release de 16 de julho corrige regressões e problemas identificados desde a Beta 1, incluindo vacuumdb em tabelas particionadas, sintaxe temporal FOR PORTION OF, logical decoding, SQL/PGQ, cálculo de autovacuum e comportamento de ferramentas. Esta lista mostra precisamente por que uma beta deve receber cargas reais de teste: os problemas aparecem na combinação entre engine, schema, extensões e operação.
O projeto declara que betas e release candidates são pre-releases, feature-frozen mas ainda sujeitas a bugs sérios e mudanças incompatíveis, e não se destinam a produção. A disponibilidade geral é apontada para setembro ou outubro, dependendo da qualidade dos testes. Portanto, a decisão de hoje é financiar aprendizagem, não antecipar migração.
Do teste à decisão de produção
- Beta 2 publicada
O projeto disponibiliza correções e pré-visualizações para teste comunitário.
- Ago. 2026Repetição interna
A equipa testa aplicação, dados, extensões, operação e retorno num ambiente isolado.
- Set.–out. 2026GA prevista
A decisão final espera a versão geral, notas finais e compatibilidade suportada.
Construa um ensaio que consiga falhar com informação útil
Parta de uma cópia de schema e dados sintéticos ou saneados que preserve distribuição, volume e casos extremos. Reproduza configurações, collation, encoding, roles, tablespaces, extensões, drivers, poolers e replicação. Execute pg_upgrade --check com o modo candidato e trate cada aviso; o próprio pg_upgrade não consegue validar compatibilidade binária de todos os módulos externos.
Meça tempos e resultado de dump/restore, upgrade, arranque, análise, consultas críticas, jobs, backups, failover e recuperação. Compare planos de execução e percentis com a versão atual sob a mesma carga. Introduza uma falha planeada para provar que o runbook de rollback funciona antes de discutir janela de produção.
Gate de avaliação PostgreSQL 19
| Frente | Teste | Evidência | Bloqueio |
|---|---|---|---|
| Compatibilidade | Schema, drivers e extensões | Inventário, versões e resultados | Extensão sem build ou comportamento divergente |
| Dados | Upgrade e dump/restore | Contagens, constraints e checksums aplicáveis | Diferença sem explicação |
| Desempenho | Carga e consultas críticas | Baseline, p50/p95/p99, CPU, I/O e planos | Regressão acima do limite |
| Operação | Backup, restore, replicação e observabilidade | Runbook executado e tempos | Recuperação não demonstrada |
| Retorno | Abortar antes/depois do corte simulado | RTO medido e decisão | Rollback destrutivo ou não ensaiado |
Feche a beta com uma lista de diferenças, não com um sim
Registe para cada execução a build, release notes, configuração, dataset, hash de scripts, extensão, resultado, regressão e issue externa. Classifique cada diferença como bug provável, incompatibilidade esperada, problema de extensão ou lacuna do teste. Volte a executar quando sair uma nova beta, RC ou GA; resultados antigos não passam automaticamente.
A decisão de produção deve esperar release final, suporte das extensões e drivers, capacidade de backup/restore, ensaio de retorno e janela aprovada. Em modos que partilham ou alteram ficheiros, como link ou swap, o rollback tem condições específicas; prefira a estratégia cujo comportamento a equipa demonstrou, não a mais rápida num slide.
- Não use dados pessoais reais quando dados sintéticos preservam o comportamento.
- Versione todos os scripts e parâmetros.
- Abra bugs com reprodução mínima útil ao projeto.
- Defina critérios quantitativos antes de ver os resultados.
Fontes consultadas
Consultadas na data de atualização indicada.
Abre numa nova janela.- 01PostgreSQL 19 Beta 2 releasedPostgreSQL Global Development Group · SYS-POSTGRES
- 02PostgreSQL beta informationPostgreSQL Global Development Group · SYS-POSTGRES
- 03PostgreSQL 19 release notesPostgreSQL Global Development Group · SYS-POSTGRES
- 04pg_upgrade documentationPostgreSQL Global Development Group · SYS-POSTGRES
- 05SQL dump backup documentationPostgreSQL Global Development Group · SYS-POSTGRES
- 06PostgreSQL versioning policyPostgreSQL Global Development Group · SYS-POSTGRES
Participar
Partilhe a análise. Acrescente contexto.
Divulgue a matéria no seu canal ou deixe uma observação ligada ao tema.
Comentários
A carregar a conversa.