Saltar para o conteúdo principal
Sistemas digitais4 min de leitura

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.

Atualizado
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.
Cena conceptual de um técnico com uma unidade de cópia de segurança junto de dois servidores genéricos, um com ligação desligada.
Avaliação isolada e recuperação como frentes separadas. Cena gerada; não mostra um teste ou uma migração realizados pela Velqory.Imagem gerada por IA sob direção editorial da Velqory.

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çãoEvidênciaResponsávelAceitação
A — avaliar Beta 4 isoladaManifesto da carga anonimizada e comparação funcionalDBA e responsável pelos dadosIsolamento confirmado; resultados críticos iguais; regressões registadas
B — escolher destino suportadoCalendário upstream, confirmação do prestador e inventário de dependênciasResponsável do serviçoDestino disponível; horizonte de suporte e incompatibilidades resolvidos
A/B — medir separadamenteLatência p95/p99, erros e concorrência em condições documentadasEquipa da aplicaçãoLimiares internos cumpridos em repetições comparáveis
B — ensaiar mudança e recuperaçãoRelatório de restauro, validação dos dados e reconciliação após escritasDBA e operaçõesTempos 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.

Consultadas na data de atualização indicada.

  1. 01PostgreSQL 19 Beta 4 Released! — 24 September 2026PostgreSQL Global Development Group · SYS-POSTGRES
  2. 02Versioning Policy — PostgreSQL 14 final release datePostgreSQL Global Development Group · SYS-POSTGRES
  3. 03Beta Information — pre-release use restrictionsPostgreSQL Global Development Group · SYS-POSTGRES
  4. 04PostgreSQL 18 documentation — Upgrading a PostgreSQL ClusterPostgreSQL Global Development Group · SYS-POSTGRES
  5. 05PostgreSQL 18 documentation — pg_upgradePostgreSQL Global Development Group · SYS-POSTGRES