Principais conclusões

•   O PostgreSQL 12 chegou ao fim de vida útil em 14 de novembro de 2024, e sua versão final da comunidade, a 12.22, foi lançada uma semana depois — não haverá mais patches de segurança nem correções de bugs por parte da comunidade.
•   O banco de dados continua em funcionamento após o fim do ciclo de vida (EOL), e esse é o problema: as vulnerabilidades CVE não corrigidas se acumulam silenciosamente até que uma auditoria de conformidade ou uma exploração torne a situação urgente.
•   Suas opções viáveis são atualizar para uma versão com suporte (18, 17, 16 ou 15) ou utilizar o suporte estendido oferecido pelo fornecedor ou pelo provedor de nuvem para manter o sistema atualizado com os patches enquanto planeja a migração.
•   Atualizações significativas do PostgreSQL exigem tempo real para testes – problemas de compatibilidade envolvendo extensões e drivers geralmente geram mais trabalho do que a própria migração.

Sua instância do PostgreSQL 12 não travou em 15 de novembro de 2024. Provavelmente nem sequer apresentou nenhum problema. E é aí que está a armadilha.

O PostgreSQL 12 chegou ao fim do ciclo de vida em 14 de novembro de 2024. A comunidade lançou uma última versão fora do ciclo, a 12.22, uma semana depois para corrigir uma regressão – e, em seguida, encerrou o ramo definitivamente. O software ainda funciona. Mas não há mais correções de segurança nem de bugs. A maioria das equipes discretamente o mantém em produção e passa a se dedicar a tarefas mais urgentes. Então, meses depois, uma vulnerabilidade recém-divulgada acaba afetando a linha 12.x, nenhum patch da comunidade está a caminho, e um sistema que “funcionava bem” de repente apresenta uma falha conhecida e irreparável.

Este guia aborda o que realmente mudou naquela data de fim de vida útil (EOL), como os riscos reais se apresentam na prática e quais são suas opções para voltar a um estado com patches aplicados — incluindo observações sinceras sobre os pontos em que cada caminho se torna complicado.

O que significa o fim do ciclo de vida do PostgreSQL 12?

O fim do ciclo de vida (EOL) significa que o Grupo Global de Desenvolvimento do PostgreSQL lançou a versão final da série 12.x e encerrou o ramo. Não haverá mais patches de segurança nem correções de bugs. Se uma vulnerabilidade recém-divulgada afetar o PostgreSQL 12, ela permanecerá sem correção por parte da comunidade, de forma permanente. Um banco de dados em fim de ciclo de vida que processe dados regulamentados ou que dê suporte a um aplicativo conectado à Internet torna-se um risco crescente cada vez que uma nova falha é identificada em seu ramo, pois não haverá mais correções por parte da comunidade.

Datas importantes de fim de vida útil (EOL) do PostgreSQL que devem ser lembradas

O projeto PostgreSQL oferece suporte a cada versão principal por cinco anos a partir de seu lançamento inicial; em seguida, lança uma versão secundária final e encerra o suporte. Não há níveis separados de “ativo” e “manutenção”, como no Node.js LTS. Trata-se de um único período de cinco anos, após o qual o ramo é descontinuado.

Versão	Lançado	Fim da vida	Status
18	Setembro de 2025	Novembro de 2030	Compatível (versão mais recente)
17	Setembro de 2024	Novembro de 2029	Compatível
16	Setembro de 2023	Novembro de 2028	Compatível
15	Outubro de 2022	Novembro de 2027	Compatível
14	Setembro de 2021	Novembro de 2026	Com apoio (termina em breve)
13	Setembro de 2020	Novembro de 2025	EOL
12	Outubro de 2019	Novembro de 2024	EOL
11	Outubro de 2018	Novembro de 2023	EOL

Se você estiver na versão 12, está duas versões principais abaixo do ramo mais antigo com suporte. Se você estiver na versão 13, você entrou para o clube EOL em novembro de 2025. A versão 14 parece segura no papel, mas seu EOL ocorre em 12 de novembro de 2026 – mais perto do que a maioria das pessoas imagina.

Por que as versões do PostgreSQL são descontinuadas

A aposentadoria de uma versão principal não significa que a comunidade esteja criando dificuldades. Trata-se de uma escolha deliberada que mantém o projeto saudável. Vários fatores impulsionam essa decisão.

O prazo de cinco anos é fixo por definição

O PostgreSQL se compromete a oferecer cinco anos de suporte para cada versão principal, contados a partir do lançamento inicial. Essa previsibilidade é realmente útil: você pode verificar qualquer versão e saber sua data de expiração com anos de antecedência.

O problema é que o tempo não se importa com o seu atraso na migração. O PostgreSQL 12 foi lançado em outubro de 2019, então seu fim de vida útil (EOL) em novembro de 2024 estava, na prática, definido desde o primeiro dia. As equipes que trataram essa data como “algum dia” viram que ela chegou na data prevista, como costuma acontecer com as datas.

A manutenção de filiais antigas acaba saindo caro

Cada versão principal suportada é um ramo separado que os mantenedores precisam atualizar, testar e lançar. A adaptação de uma única correção de segurança para cinco ou seis ramos ativos é um verdadeiro trabalho de engenharia, realizado pelos colaboradores do projeto e pelas empresas que os patrocinam.

Em determinado momento, o custo de manter um branch antigo ativo passa a ser maior do que o benefício. Os caminhos do código se divergem. A infraestrutura de testes fica ultrapassada. Uma correção que seria simples no branch atual pode exigir uma intervenção complicada em uma base de código com cinco anos de idade. Desativar o branch mais antigo permite que o projeto dedique essa energia às versões que a maioria das pessoas realmente utiliza.

As atualizações retroativas de segurança têm um prazo de validade

Algumas vulnerabilidades são fáceis de corrigir em códigos antigos. Outras dependem de uma arquitetura que foi alterada nas versões mais recentes, e a retroportação dessas correções para um ramo muito mais antigo pode variar de algo trabalhoso a genuinamente arriscado. A própria retroportação pode introduzir regressões em caminhos de código que ninguém executa há anos.

Quando uma versão chega ao fim da vida útil (EOL), o ônus do backporting recai sobre você ou sobre quem quer que você contrate para cuidar disso.

Riscos de utilizar uma versão do PostgreSQL em fim de vida útil (EOL)

Os riscos de continuar usando o PostgreSQL 12 não são hipotéticos. Eles se agravam quanto mais você demora.

Vulnerabilidades de segurança sem correção

Qualquer vulnerabilidade divulgada no PostgreSQL 12 após o fim de seu ciclo de vida (EOL) permanecerá sem correção por parte da comunidade, ponto final. A versão 12.22, lançada fora do ciclo normal em 21 de novembro de 2024, foi a última versão de correção que a versão 12 receberá — ela foi lançada para corrigir uma regressão na versão 12.21, e não para estender o suporte. Qualquer coisa divulgada depois disso ou não afeta a versão 12, ou, se a afetar, nunca receberá uma correção da comunidade.

A tendência geral agrava ainda mais a situação. Os rastreadores de vulnerabilidades registraram 16 CVEs do PostgreSQL no primeiro semestre de 2026 – já mais do que em todo o ano de 2025 – com uma pontuação média de gravidade acima de 7. A lançamento de segurança de maio de 2026 , por si só, corrigiu 11 vulnerabilidades nos ramos suportados, com pontuações de gravidade de até 8,8. Nem todas elas afetam a versão 12. A preocupação é o que acontece quando uma falha recém-divulgada afeta essa versão: a comunidade não produz mais uma correção para ela.

Para obter mais detalhes sobre como proteger seu ambiente contra riscos decorrentes de falhas de segurança não corrigidas, você pode conhecer melhor as práticas recomendadas de segurança do PostgreSQL em nosso guia detalhado. Você também pode explorar as vulnerabilidades do PostgreSQL e os riscos de segurança que elas podem causar em nosso guia aprofundado.

Essa é exatamente a lacuna que o suporte estendido oferecido pelo fornecedor se propõe a preencher. Mais detalhes sobre isso na seção de opções abaixo.

Falhas em conformidade e auditoria

PCI DSS exige explicitamente a correção de vulnerabilidades conhecidas e o acompanhamento de tecnologias em fim de vida útil dentro do escopo. A HIPAA e SOC 2 não mencionam diretamente o software em fim de vida, mas os avaliadores tratam um banco de dados que não pode mais receber patches de segurança como uma falha prestes a ocorrer. De qualquer forma, “o fornecedor parou de aplicar patches” é uma posição difícil de defender, independentemente do nível de segurança do restante da sua infraestrutura.

Os auditores verificam diretamente o status do suporte às versões – por meio de questionários, análises de vulnerabilidades e inventários de ativos. “Estamos trabalhando na atualização” não é uma resposta convincente quando a data de fim de vida útil (EOL) já passou, em novembro de 2024. As constatações acarretam custos reais: negócios perdidos, prazos para correção e, em setores regulamentados, multas.

Desvio do ecossistema

A segurança chama a atenção, mas o problema mais gradual é que tudo o que gira em torno do banco de dados está deixando de usar a versão 12. Os mantenedores de extensões deixam de realizar testes com ela. Os drivers de cliente deixam de oferecer suporte. Os provedores gerenciados cobram sobretaxas por suporte estendido, bloqueiam novas implantações ou programam atualizações forçadas.

Nada disso é catastrófico por si só, mas vai se acumulando. Eventualmente, um mantenedor de biblioteca lança uma versão que pressupõe o comportamento do PostgreSQL 14 ou superior, ou sua integração de monitoramento deixa de oferecer suporte à versão 12.x. Você acaba com um banco de dados que não pode alterar com segurança e do qual não consegue sair facilmente.

Opções após o fim do ciclo de vida do PostgreSQL 12

Você tem quatro opções viáveis. A escolha certa depende da sua tolerância ao risco: você consegue lidar com as interrupções causadas por uma atualização agora, ou precisa manter o sistema atualizado e em conformidade enquanto planeja um caminho de migração estável?

1. Suporte estendido oferecido pelo fornecedor

Se você não puder migrar imediatamente, mas também não puder continuar usando um software sem patches, o suporte estendido é a solução intermediária. Alguns fornecedores oferecem esse serviço. O Suporte de Ciclo de Vida Ilimitado da TuxCare atualmente abrange o PostgreSQL 13, e a empresa anunciou planos para incluir a versão 14 antes de sua data de fim de vida útil (EOL).

O objetivo do suporte estendido não é evitar a atualização para sempre. É transformar um prazo rígido em um projeto planejado. Em vez de uma migração de emergência encaixada em um sprint entre o desenvolvimento de novos recursos, você conta com uma instância corrigida e a flexibilidade necessária para migrar quando estiver pronto, em vez de quando uma vulnerabilidade CVE ou um auditor o obrigar a fazê-lo.

Essa opção é ideal para equipes que atuam em ambientes regulamentados, aquelas que utilizam configurações altamente personalizadas ou qualquer pessoa cujo prazo realista para a migração ainda esteja a meses de distância. Ela também oferece um plano de aplicação de patches documentado para apresentar aos auditores enquanto a atualização propriamente dita ainda está em andamento.

2. Atualizar para o PostgreSQL 18

O PostgreSQL 18 é a versão atual, com suporte até novembro de 2030. Passar diretamente para essa versão oferece o maior intervalo de tempo até que você precise repetir esse exercício, além dos recursos e melhorias de desempenho mais recentes.

A desvantagem é a distância: passar da versão 12 para a 18 abrange seis saltos de versão principal, o que significa mais mudanças de comportamento a serem verificadas de uma só vez — diferenças no planejador, configurações obsoletas e compatibilidade de extensões em todos os aspectos. Use o pg_upgrade (com os binários da nova versão instalados junto com os antigos) em vez de um dump e restauração completos, mas reserve um tempo considerável para o ambiente de teste:

pg_upgrade \

  –old-datadir /var/lib/postgresql/12/main \

  –new-datadir /var/lib/postgresql/18/main \

  –old-bindir /usr/lib/postgresql/12/bin \

  –new-bindir /usr/lib/postgresql/18/bin \

  –verificar

Os caminhos mostrados são os padrões do Debian/Ubuntu – ajuste-os de acordo com a sua distribuição. Execute o comando com –check primeiro: ele identifica muitos problemas graves antes de você se comprometer com qualquer coisa, embora não detecte todos os problemas no nível do aplicativo ou de desempenho.

3. Atualize para o PostgreSQL 17, 16 ou 15 (ainda com suporte)

Se a versão 18 parecer um salto muito grande, o PostgreSQL 17 (fim de suporte em novembro de 2029), o 16 (fim de suporte em novembro de 2028) e o 15 (fim de suporte em novembro de 2027) ainda contam com suporte da comunidade e apresentam um comportamento mais próximo do da versão 12. Muitas equipes optam por uma dessas versões como um passo intermediário deliberado: tempo de suporte suficiente para fazer diferença, com menos surpresas do que a versão mais recente.

No entanto, tenha o calendário em mente. Escolher a versão 15 em 2026 lhe dá apenas um ano e meio antes de você precisar voltar a planejar o fim do ciclo de vida (EOL) – as versões 17 ou 16 oferecem à estratégia intermediária uma margem de manobra real. Optar por uma dessas em vez da 18 faz sentido quando suas extensões ainda não foram certificadas para a versão mais recente ou quando você prefere uma versão com um histórico de produção mais longo.

Dica profissional: Execute SELECT * FROM pg_extension; na sua instância 12.x em produção antes de escolher um destino e, em seguida, verifique cada extensão em relação à versão candidata. Geralmente, são as extensões — e não o núcleo do PostgreSQL — que fazem com que as atualizações fiquem paralisadas no meio do projeto.

4. Suporte Estendido para Nuvem Gerenciada

Se você utiliza o Amazon RDS, o Google Cloud SQL ou uma implantação qualificada do Azure Database for PostgreSQL, seu provedor pode oferecer suporte estendido pago para determinadas versões em fim de vida (EOL) – a disponibilidade e as regras de inscrição variam de acordo com o serviço e a versão. O Amazon RDS transferiu o PostgreSQL 12 para o Suporte Estendido do RDS após o término do período de suporte padrão em 28 de fevereiro de 2025, com sobretaxas por vCPU. O Google Cloud SQL começou a cobrar taxas de suporte estendido para versões principais em fim de vida útil (EOL) em 1º de maio de 2025. O Azure agora inscreve automaticamente servidores em versões sem suporte no Suporte Estendido , com cobrança pela versão 13 a partir de 1º de agosto de 2026.

Isso permite que você receba atualizações de segurança gerenciadas pelo provedor sem precisar manter seus próprios backports do PostgreSQL, o que é realmente útil. No entanto, as sobretaxas aumentam com o tempo — a tarifa da AWS sobe após os dois primeiros anos —, portanto, considere isso como um período de carência limitado, e não como uma estratégia de longo prazo. Leia atentamente os preços por instância antes de presumir que essa seja a opção mais barata.

Aqui está a decisão em resumo:

Se a sua situação for…	Melhor jogada
Não é possível migrar tão cedo; é preciso manter os patches atualizados e a conformidade em dia	Suporte estendido oferecido pelo fornecedor (por exemplo, o Endless Lifecycle Support da TuxCare)
Pronto para migrar, quer o maior prazo possível de suporte	Atualizar para o PostgreSQL 18
Pronto para migrar, quer menos surpresas	Atualize para a versão 17 ou 16
Na nuvem gerenciada, ganhando um respiro a curto prazo	Suporte estendido do provedor

Planejando a migração antes que se torne urgente

As equipes que lidam bem com o fim da vida útil (EOL) tratam isso como qualquer outro projeto programado. As que enfrentam dificuldades tendem a considerar a data de fim da vida útil como o momento de começar a pensar no assunto, o que já é cerca de um ano tarde demais.

Um plano de migração viável geralmente abrange:

•   Inventário. Todas as instâncias 12.x, incluindo a réplica esquecida e o servidor de análise que ninguém assume como responsável.
•   Auditoria de dependências. Extensões, drivers de cliente, ORMs e ferramentas de replicação, todos verificados em relação à sua versão de destino.
•   Uma decisão sobre a versão-alvo. Escolhida com base na compatibilidade com extensões e no prazo de suporte, e não por intuição.
•   Um caminho de atualização comprovado. O `pg_upgrade` ou a replicação lógica para tempo de inatividade praticamente nulo, testados no ambiente de teste antes de você mexer na produção.
•   Uma ponte de transição. Como se manter seguro até o dia da migração. Isso geralmente significa suporte estendido do fornecedor ou da nuvem; controles compensatórios documentados são a alternativa menos eficaz.
•   Um plano de reversão. Porque algo vai te pegar de surpresa, e você vai querer uma saída que não seja “restaurar a partir do backup da noite passada”.

A realidade: Os fornecedores adoram chamar as grandes atualizações de “indolores”. Mas elas não são. Mesmo uma execução limpa do pg_upgrade exige que você revalide extensões, reajuste configurações e acompanhe as mudanças nos planos de consulta. Para um ambiente de produção com dependências significativas, planeje semanas de testes, não apenas uma janela de manutenção.

O que fazer se o PostgreSQL 12 ainda estiver em produção

O PostgreSQL 12 não vai deixar de funcionar, e é exatamente por isso que é fácil ignorá-lo até que um CVE ou uma auditoria torne a questão urgente. A conclusão sincera: tome uma decisão consciente. Faça a atualização para uma versão com suporte, se for possível. Se não for, garanta a aplicação de patches para que o “ainda não” não se transforme em “exposto por um ano”.

No que diz respeito ao suporte estendido, a TuxCare oferece suporte à versão 13 atualmente, caso você precise de uma opção comercial de correção de falhas enquanto planeja a atualização, com a cobertura da versão 14 anunciada antes do fim do ciclo de vida (EOL) dela. Verifique a cobertura exata da versão com qualquer fornecedor antes de considerar o suporte estendido como sua solução provisória.

Comece mapeando sua infraestrutura da versão 12.x: quantas instâncias, quais extensões e o que depende delas. Esse inventário, por si só, geralmente deixa claro qual caminho faz mais sentido. O pior cenário é aquele em que você nem sequer faz uma escolha.

Perguntas frequentes