PostgreSQL 19 Beta 4: testar o futuro sem adiar a saída do 14
As funcionalidades retiradas em setembro obrigam a rever expectativas. O fim do suporte ao 14 exige uma decisão de produção separada.
- Autoria
- Redação Velqory
- Verificação
- 05/10/2026 — Europe/Lisbon
- Período de recuperação editorial
- 13/09–05/10/2026
- Natureza
- Factos oficiais e recomendações editoriais; não relata um upgrade ou benchmark realizado pela Velqory.
- Revisão
- Rever quando sair um RC ou a versão final do 19, mudar a política de suporte ou o prestador confirmar o calendário; em qualquer caso, antes da mudança de produção.

Em resumo
Duas frentes para outubro: avaliar o PostgreSQL 19 num laboratório isolado e escolher um destino suportado para o 14, com critérios internos de aceitação e recuperação ensaiada.
- A Beta 4 retirou funcionalidades anunciadas anteriormente; não baseie dependências de produção nessas promessas.
- O suporte upstream ao PostgreSQL 14 termina em 12 de novembro de 2026; confirme separadamente o calendário do alojamento.
- Autorize a mudança apenas com compatibilidade verificada, latência medida e restauro e reconciliação ensaiados.
O que mudou em 24 de setembro
O comunicado oficial da Beta 4 retirou SQL/PGQ, atualizações e eliminações temporais com FOR PORTION OF, divisão e fusão de partições e ativação/desativação de checksums online. Previa um RC no início de outubro e uma possível versão final nesse mês, não uma data garantida. Na consulta de 5 de outubro, a página beta ainda identificava a Beta 4. Não assumimos disponibilidade geral do 19.
O prazo do 14 não depende do 19
A política do projeto fixa 12 de novembro de 2026 como data final do PostgreSQL 14. É o calendário upstream, não uma confirmação do contrato de um serviço alojado. Peça ao prestador a data aplicável, eventuais condições de suporte prolongado e versões disponíveis; não presuma que coincidem.
Recomendação Velqory: mantenha responsáveis e entregáveis distintos para explorar o 19 e retirar o 14. Escolha um destino estável e suportado com margem operacional; uma expectativa de lançamento não deve ser a única saída planeada.
Frente A: uma beta num laboratório descartável
O projeto desaconselha betas em produção e em projetos de desenvolvimento ativos. A nossa proposta é um laboratório independente, sem tráfego de clientes, credenciais de produção ou capacidade de escrever no sistema real.
Use uma carga anonimizada que preserve distribuição, cardinalidade e concorrência relevantes. Remova identificadores e segredos; confirme que não permite reidentificação ou use dados sintéticos. Registe versão, configuração, consultas e resultados esperados.
Compare percursos críticos com a referência atual. Uma regressão deve produzir um caso mínimo reproduzível, sem dados sensíveis, e uma decisão: investigar, reportar ou excluir a dependência.
Frente B: compatibilidade antes de escolher o destino
A documentação distingue migração major de atualização menor e apresenta dump/restauro, pg_upgrade e replicação lógica como caminhos. A escolha requer leitura das notas de migração das versões atravessadas; não é uma simples troca de executáveis.
Inventarie extensões, drivers, ferramentas de administração e consumidores de replicação lógica. Obtenha suporte declarado e teste autenticação, tipos, consultas preparadas, sincronização inicial, interrupção e retoma. Descreva publicações, subscrições e passos de transição; o ensaio recomendado deve cobrir cada consumidor. Uma incompatibilidade sem responsável deve bloquear a escolha.
Matriz original: duas frentes, provas diferentes
Plano recomendado, não resultados obtidos. Cada linha pede evidência produzida pela equipa responsável. Os limiares pertencem ao serviço: devem ser acordados antes de medir, para evitar transformar um resultado conveniente num critério de aceitação.
Decisão de outubro: avaliação e retirada
Recomendação Velqory. A frente A não autoriza a mudança da frente B.
| Frente / ação | Evidência | Responsável | Aceitação |
|---|---|---|---|
| A — avaliar Beta 4 isolada | Manifesto da carga anonimizada e comparação funcional | DBA e responsável pelos dados | Isolamento confirmado; resultados críticos iguais; regressões registadas |
| B — escolher destino suportado | Calendário upstream, confirmação do prestador e inventário de dependências | Responsável do serviço | Destino disponível; horizonte de suporte e incompatibilidades resolvidos |
| A/B — medir separadamente | Latência p95/p99, erros e concorrência em condições documentadas | Equipa da aplicação | Limiares internos cumpridos em repetições comparáveis |
| B — ensaiar mudança e recuperação | Relatório de restauro, validação dos dados e reconciliação após escritas | DBA e operações | Tempos e perda máxima de dados dentro dos objetivos aprovados |
Retorno não significa upgrade ao contrário
pg_upgrade migra para uma versão major posterior; não promete um downgrade. Com --link, iniciar o novo cluster torna inseguro reutilizar o antigo. --check verifica compatibilidade sem alterar os dados, mas não certifica a aplicação.
Na nossa análise, o cluster antigo não contém as transações aceites no novo. Antes da mudança, ensaie captura e reconciliação, incluindo conflitos e duplicações; defina quem pode interromper escritas. Não presuma replicação inversa automática. Exija restauro testado numa instância separada e validação de dados e aplicação; documente perdas e tempo de recuperação.
A decisão útil para outubro
Perspetiva Velqory: a retirada de funcionalidades pede uma revisão do plano, não uma corrida para outra promessa. Identifique consultas ou projetos que dependiam dessas capacidades e retire-as dos critérios obrigatórios do destino. O laboratório pode continuar a informar decisões futuras sem atrasar a retirada do 14.
Para equipas portuguesas, marque a janela operacional, contactos do alojamento e cobertura de recuperação com antecedência. Feche outubro com um destino justificado, um ensaio repetível e condições explícitas para avançar ou parar. Este é um plano recomendado: não apresentamos ganhos de desempenho, retorno financeiro ou experiência de migração interna como factos.
Fontes consultadas
Consultadas na data de atualização indicada.
Abre numa nova janela.- 01PostgreSQL 19 Beta 4 Released! — 24 September 2026PostgreSQL Global Development Group · SYS-POSTGRES
- 02Versioning Policy — PostgreSQL 14 final release datePostgreSQL Global Development Group · SYS-POSTGRES
- 03Beta Information — pre-release use restrictionsPostgreSQL Global Development Group · SYS-POSTGRES
- 04PostgreSQL 18 documentation — Upgrading a PostgreSQL ClusterPostgreSQL Global Development Group · SYS-POSTGRES
- 05PostgreSQL 18 documentation — pg_upgradePostgreSQL 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.