PostgreSQL 14 perde suporte em novembro: upgrade agora

PostgreSQL 14 perde suporte oficial em novembro de 2026. Depois dessa data, não há mais patches de segurança — qualquer CVE descoberta fica aberta até você migrar. O release de 14 de maio de 2026 (versões 18.4, 17.10, 16.14, 15.18 e 14.23) corrigiu 11 vulnerabilidades de segurança e mais de 60 bugs, e é provavelmente o último ou penúltimo patch que o PG 14 vai receber. Quem roda produção nessa versão tem uns seis meses pra planejar o salto — e "planejar" é a palavra-chave, porque upgrade de major version em PostgreSQL não é apt upgrade e pronto.

Por que o upgrade não pode esperar dezembro

A política de suporte do PostgreSQL cobre cada major version por cinco anos. PG 14 saiu em setembro de 2021; o fim de vida está marcado para 12 de novembro de 2026. Depois disso, o time de release não emite mais patches — nem pra falhas críticas de segurança. Quem já passou por isso sabe: o custo de migrar sob pressão (com CVE aberta e cliente cobrando) é ordens de grandeza maior do que migrar com calma.

Outro motivo concreto: extensões populares (PostGIS, pgvector, TimescaleDB) costumam dropar suporte a versões EOL dentro de um ou dois releases. O ecossistema se move junto, e ficar pra trás cria uma cascata de incompatibilidades que complica muito mais do que o upgrade em si.

PG 15, 16 ou 17 — qual versão mirar

Pular uma major version é normal em PostgreSQL. O pg_upgrade suporta salto de qualquer major pra qualquer major mais recente. A decisão real é entre estabilidade comprovada e longevidade de suporte.

PG 15 já está na metade da vida útil — migrar pra ele é trocar um problema por outro em 18 meses. PG 16 é a opção conservadora e segura. PG 17 dá três anos de suporte à frente e traz incremental backup nativo, que simplifica muito a rotina de backup em bases grandes. A recomendação direta: mire no PG 17 salvo se alguma extensão crítica ainda não suporta (verifique antes de decidir).

Os dois caminhos de upgrade: pg_upgrade vs dump/restore

Existem duas estratégias consolidadas pra major upgrade em PostgreSQL. A escolha depende do tamanho da base e da tolerância a downtime.

• pg_upgrade (in-place) — converte o data directory direto. Downtime proporcional ao número de tabelas, não ao volume de dados. Em bases de algumas dezenas de GB, pode levar minutos. O modo --link cria hard links em vez de copiar arquivos, reduzindo tempo e espaço em disco.
• pg_dump + pg_restore (logical) — exporta tudo como SQL e reimporta na nova versão. Downtime proporcional ao tamanho total dos dados. Útil quando se quer reorganizar schema, trocar encoding ou mudar de collation. Também é o único caminho quando se muda de arquitetura (ex: migrar de self-hosted pra managed).

Checklist de upgrade: o que fazer antes de tocar em produção

Upgrade de major version não é operação pra improvisar. O checklist abaixo cobre os pontos que costumam causar dor quando esquecidos.

1. Auditar extensões. Liste tudo com SELECT * FROM pg_extension;. Verifique se cada extensão tem versão compatível com o PG alvo. PostGIS, pgvector, pg_cron e pg_stat_statements são as que mais causam bloqueio.
2. Testar em staging com dados reais. Clone a base de produção (ou um snapshot recente) e rode o upgrade completo. Meça tempo de downtime, espaço em disco e valide que a aplicação conecta e funciona.
3. Verificar queries com EXPLAIN ANALYZE. O query planner muda entre major versions. Queries que tinham plano eficiente em PG 14 podem mudar de comportamento. Rode as top 20 queries mais lentas no staging e compare.
4. Atualizar connection strings e poolers. Se usa PgBouncer ou Supavisor, o upgrade pode exigir restart do pooler ou ajuste de versão de protocolo.
5. Rodar `ANALYZE` logo após o upgrade. O pg_upgrade não carrega estatísticas de tabela. Sem ANALYZE, o planner vai operar cego e gerar planos ruins.
6. Agendar janela de manutenção com folga. Mesmo com pg_upgrade rápido, algo pode dar errado. Bloqueie o dobro do tempo estimado.
7. Backup completo antes de iniciar. pg_basebackup ou snapshot de disco. Se algo quebrar, o caminho de volta é restaurar o backup — não religar o cluster antigo.

Exemplo prático: pg_upgrade de PG 14 para PG 17

O fluxo abaixo assume instalação em Linux (Debian/Ubuntu) com pacotes oficiais do repositório PostgreSQL. Adapte caminhos se usa Docker ou managed service.

O --check no passo 3 é o que separa um upgrade tranquilo de uma noite em claro. Ele valida compatibilidade de extensões, data types e encoding sem tocar nos dados. Se falhar, o relatório diz exatamente o que precisa ser resolvido antes.

Armadilhas que aparecem depois do upgrade

O upgrade em si costuma ser a parte mais previsível. Os problemas aparecem nos dias seguintes, quando o tráfego real estressa caminhos que o staging não cobriu.

• Query plans diferentes. O planner do PG 17 tem heurísticas novas. Uma query que usava index scan em PG 14 pode virar seq scan em PG 17 se as estatísticas estiverem desatualizadas ou se o custo estimado mudou. Solução: ANALYZE completo + monitorar pg_stat_statements na primeira semana.
• Extensões com breaking changes. PostGIS 3.x pra 4.x muda funções e tipos. pgvector pode mudar formato de índice entre majors. Sempre leia o changelog da extensão, não só do PostgreSQL.
• Replication slots quebrados. Se usa logical replication, slots criados em PG 14 não migram automaticamente. Precisa recriar no PG 17 e refazer o snapshot inicial.
• Configurações de tuning desatualizadas. shared_buffers, work_mem, effective_cache_size — revise. PG 17 tem defaults diferentes e comportamento otimizado pra alguns parâmetros. Copiar postgresql.conf do PG 14 sem revisar é pedir performance degradada.
• Permissões e roles. pg_upgrade carrega roles, mas vale auditar. Mudanças no modelo de segurança entre versions (como defaults de pg_read_all_data) podem abrir ou fechar acessos inesperados.

Timeline sugerida: de agora até novembro

Seis meses parece folga, mas o tempo derrete quando há staging pra montar, extensões pra validar e janela de manutenção pra negociar. Uma timeline realista:

1. Maio–Junho: auditar extensões, versão atual do PG, e documentar queries críticas (top 20 por tempo de execução). Decidir versão-alvo.
2. Julho: montar staging com clone de produção. Rodar upgrade completo. Comparar EXPLAIN ANALYZE das queries críticas.
3. Agosto: resolver incompatibilidades encontradas em staging. Atualizar connection pooler, variáveis de ambiente, scripts de backup.
4. Setembro: segundo round de teste em staging com dados frescos. Validar que CI/CD funciona contra a nova versão.
5. Outubro: agendar janela de manutenção. Comunicar downtime. Fazer upgrade em produção com backup prévio.
6. Novembro (antes do dia 12): monitorar performance da primeira semana. Ajustar tuning se necessário. Remover cluster PG 14.

Quem já migrou a camada de dados pra UUID v7 no PostgreSQL sabe que mudanças em banco de produção exigem essa cadência — testar, validar, repetir, só então executar.

A diferença entre timestamp e datetime no banco é o tipo de detalhe que muda entre major versions — defaults de precisão, comportamento de timezone. Vale revisar o schema durante o processo de upgrade pra não carregar decisões técnicas de 2021 adiante sem questionar.

Upgrade de major version em PostgreSQL é uma das tarefas mais previsíveis em infraestrutura — quando planejada. O pg_upgrade funciona bem, a documentação é sólida, e o processo tem décadas de maturidade. O risco real nunca é a ferramenta; é adiar até que uma CVE force a migração sob pressão, num sábado de noite, sem staging.