PostgreSQL 14 encerra suporte e obriga plano de migração em produção

A versão 14 recebeu sua última atualização de segurança nesta semana. Um roteiro de upgrade detalhado pela Stormatics mostra as três decisões que definem se a migração vira problema ou rotina.

O fim de vida da versão 14

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 → 14 recebeu nesta quinta-feira, 12 de novembro de 2026, sua última atualização de manutenção, segundo post de Umair Shahid publicado em 11 de novembro de 2026 no Planet PostgreSQL, assinado pela Stormatics. A partir de agora, nenhuma falha de segurança ou bug encontrado na versão 14 recebe correção da comunidade. O banco continua rodando normalmente, mas toda vulnerabilidade descoberta a partir desta data permanece aberta em quem seguir operando essa versão em produção.

Quem está na versão 14, ou mesmo na 15 (que perde suporte em 11 de novembro de 2027), tem pouco tempo para decidir o próximo passo. Shahid resume o problema em três decisões: para qual versão migrar, qual método usar e como conduzir a virada de tráfego sem incidente. É esse roteiro que vale destrinchar, com os riscos que o texto original só menciona de passagem.

Decisão 1: para onde migrar

Cada versão major do PostgreSQL recebe cinco anos de suporte da comunidade. As janelas informadas pela fonte são estas:

O argumento de Shahid é direto: o esforço de uma migração major (checar extensões, testar a aplicação, planejar a virada) é praticamente o mesmo, não importa o destino escolhido. Migrar de 14 para 15 ou 16 compra um ou dois anos de sobrevida pelo mesmo trabalho; migrar direto para 18 compra quatro. Na prática, pular para a versão mais recente suportada costuma ser a decisão mais racional, desde que cada extensão em uso já tenha build disponível para ela.

Decisão 2: qual método de upgrade

Existem três caminhos para atravessar uma versão major, e cada um define quanto tempo a aplicação fica fora do ar.

• Dump and restore: mais simples de raciocinar, mas o tempo de indisponibilidade cresce junto com o tamanho do banco. Para bases multi-terabyte, a fonte descarta a opção de saída.
• pg_upgrade com a flag --link: ferramenta oficial da comunidade para upgrade in-place. A flag cria hard links em vez de copiar os arquivos de dados, então o tempo do passo de upgrade não depende do volume armazenado. Em um cliente da Stormatics, uma base de produção de 100 GB levou menos de 10 minutos de downtime nesse passo específico.
• Blue-green upgrade: a opção de menor indisponibilidade. O cluster atual (blue) segue servindo produção enquanto um cluster novo na versão alvo (green) é construído ao lado, recebendo cada mudança em tempo real via replicação lógica. A virada vira uma pausa de escrita de segundos, e as conexões existentes se reconectam ao cluster novo.

Dois cuidados específicos do pg_upgrade merecem atenção redobrada do DBA. Estatísticas não são copiadas no processo, então rodar ANALYZE antes de liberar tráfego é obrigatório, sob pena de o otimizador escolher planos de execução ruins logo na primeira hora. O diretório de dados antigo, por sua vez, deve ser tratado como inutilizável assim que o novo cluster sobe; quem quer rota de rollback precisa tirar um snapshot de filesystem antes de começar, porque o pg_upgrade em si não oferece essa rede de segurança.

O blue-green upgrade não serve para todo cluster. Large objects, tabelas sem chave primária e mudanças de schema durante a migração podem impedir uma virada quase sem indisponibilidade, e é preciso mapear essas restrições antes de prometer prazo curto a ninguém.

O blue-green é o método que usamos sempre que um cluster se qualifica.

Umair Shahid, StormaticsA blue-green upgrade is the method we use wherever a cluster qualifies.

Quando o cluster não se qualifica, o pg_upgrade --link vira o plano B, com indisponibilidade medida em minutos em vez de segundos.

Decisão 3: como conduzir a virada

A fonte descreve a sequência usada pela Stormatics em upgrades de produção, e ela vale como checklist mínimo para qualquer equipe que vá tocar essa virada internamente:

1. Review: checar banco, extensões, replicação, pipelines conectados e configuração de conexões; todo risco encontrado precisa ser resolvido antes de avançar.
2. Plan: escrever um runbook passo a passo com plano de rollback, e combinar a janela de virada com quem é dono da aplicação.
3. Prepare: construir o cluster green na versão alvo e mantê-lo sincronizado com produção via replicação lógica.
4. Test: validar dados, sequences e as queries principais da aplicação, e ensaiar a virada onde existir ambiente de teste.
5. Switch over: mover o tráfego em uma chamada ao vivo com o time de aplicação, confirmando a saúde do sistema logo depois.
6. Support: manter o cluster blue disponível como rollback e monitorar o green de perto.

Dois detalhes técnicos escapam de quem só lê o anúncio por alto. Sequences não são replicadas pela replicação lógica, então seus valores precisam ser ajustados manualmente no cluster green antes do corte, sob risco de colisão de chave primária logo na primeira escrita. E o pico de reconexões no momento da virada pode sobrecarregar um pool de conexões, então vale confirmar antes que a aplicação reconecta sozinha e que o pooler aguenta a rajada.

Depois da virada: validação e janela de segurança

Uma validação curta encerra o processo, segundo a fonte. Confirmar a versão em execução, checar índices inválidos consultando pg_index (a query deve retornar zero linhas), comparar as versões de extensão instaladas com as disponíveis e atualizar o que estiver atrasado. Os logs merecem acompanhamento nas primeiras horas de tráfego real, porque é quando planos de execução ruins ou locks inesperados aparecem.

A Stormatics mantém o cluster blue disponível por 5 dias após o corte, com a replicação rodando no sentido inverso (do green de volta para o blue). Isso permite apontar a aplicação de volta para o cluster antigo sem perder nenhuma escrita feita após a virada, caso algo dê errado depois que o tráfego já estiver no ar na versão nova.

Serviços gerenciados seguem a mesma lógica

Amazon RDS, Aurora, Cloud SQL, Azure↳Azure76 conteúdosDeploy de Azure Stream Analytics job com CI/CD usando Azure PipelinesDevSecOps · mai 2019Azure – Como criar uma base de dados SQL no Microsoft Azure pronta para ser utilizadaData · abr 2019Azure Static Web Apps com Vue.js e Visual Studio CodeDevSecOps · out 2023Ver tudo em DevSecOps → Database e Supabase têm cada um seu próprio caminho de upgrade, mas as três decisões continuam valendo: versão alvo, método e disciplina na virada. No caso específico da AWS, segundo a Stormatics, os Blue/Green Deployments do RDS e do Aurora usam a mesma replicação lógica para upgrades major; vale checar diretamente na documentação oficial da AWS se o cluster específico se qualifica para a virada e que garantias de rollback existem antes de depender desse caminho.

O que muda para quem sustenta banco em produção

A Stormatics cita um caso concreto: clusters de produção de um provedor de software bancário migrados da versão 13 para a 17 com indisponibilidade próxima de zero. É o tipo de resultado que só se sustenta quando o review da etapa 1 é levado a sério, e não tratado como formalidade antes de "só rodar o script".

Para quem decide tocar essa migração com a própria equipe, em vez de contratar o serviço da Stormatics (oferecido a partir de 9.990 dólares por cluster, segundo a fonte), o roteiro acima é reproduzível sem custo adicional além do tempo de engenharia. A diferença entre uma virada tranquila e um incidente de produção não está na ferramenta escolhida, mas no quanto da etapa de review foi feita antes de qualquer comando rodar: extensões sem build para a versão alvo, tabelas sem chave primária e índices inválidos deixados para trás costumam estar entre os motivos de upgrade que parecia pronto e não estava.

Vale registrar o que o material não resolve: ele não discute o comportamento de réplicas de leitura durante a janela de replicação lógica, nem o efeito de triggers e de extensões que dependem de APIs internas do PostgreSQL ao longo do salto de versões. Quem administra esse tipo de cluster faz bem em testar justamente esses pontos antes de marcar a data do corte.

Fonte: Planet PostgreSQL