Para planejar upgrades de banco de dados e manter os clusters em execução em versões compatíveis do PostgreSQL, use as políticas de suporte de versões principais e secundárias do banco de dados, os cronogramas de ciclo de vida e os cronogramas de descontinuação do AlloyDB para PostgreSQL.
Para informações sobre as políticas de versão do AlloyDB Omni, consulte Políticas de versão do banco de dados do AlloyDB Omni.Políticas de versão do AlloyDB
As instâncias do AlloyDB executam um servidor de banco de dados criado e mantido pelo Google Cloud que é totalmente compatível com o PostgreSQL. Você controla com qual versão principal do PostgreSQL suas instâncias são compatíveis. O AlloyDB mantém a compatibilidade de versões secundárias das instâncias atualizada automaticamente.
Cada cluster do AlloyDB é compatível com uma versão principal específica do PostgreSQL, como o PostgreSQL 18. Você escolhe a versão principal ao criar o cluster. Depois de escolher uma versão principal, o cluster a mantém durante todo o ciclo de vida, a menos que você inicie um upgrade de versão principal. É possível fazer upgrade de um cluster realizando um upgrade de versão principal no local ou migrando os dados do cluster para um novo cluster.
Cada instância do AlloyDB executa um serviço de banco de dados compatível com uma versão secundária específica do PostgreSQL, por exemplo, 16.3. O AlloyDB lança atualizações de compatibilidade de versões secundárias várias vezes por ano e as aplica automaticamente às instâncias. Essas atualizações mantêm todas as instâncias atualizadas com as correções de bugs e patches de segurança mais recentes disponíveis para a versão principal.
Política de versão principal
Nesta seção, descrevemos o ciclo de vida de compatibilidade e suporte para as versões principais do AlloyDB.
Suporte regular
OGoogle Cloud tem como objetivo oferecer suporte rápido para a compatibilidade do AlloyDB com novas versões principais do PostgreSQL. O momento desse suporte depende do produto do AlloyDB:
AlloyDB para PostgreSQL: Google Cloud tem como objetivo oferecer compatibilidade com uma nova versão principal do PostgreSQL em até cinco meses após o lançamento da disponibilidade geral pela comunidade de desenvolvedores do PostgreSQL.
A primeira fase é o suporte regular. Durante o suporte regular, o AlloyDB fornece atualizações de versões secundárias e de manutenção, além de aplicar correções de segurança às instâncias. O AlloyDB oferece suporte regular a uma versão principal desde que a comunidade de desenvolvedores do mecanismo de banco de dados ofereça suporte da comunidade, por pelo menos cinco anos. Depois que a versão principal atinge o fim da vida útil (EOL, na sigla em inglês) pela comunidade, ela entra na fase de suporte estendido do ciclo de vida.
Estas são diretrizes gerais. Os horários reais de lançamento de novas versões podem variar.
Suporte estendido
OGoogle Cloud usa a programação de fim de vida útil da comunidade do PostgreSQL ao planejar o fim do suporte regular para compatibilidade com qualquer versão principal do PostgreSQL.
Para as versões principais do AlloyDB que chegam ao EOL, o AlloyDB oferece suporte estendido. Com o suporte estendido, é possível continuar executando as instâncias do AlloyDB por três anos depois que a comunidade de desenvolvedores parar de oferecer suporte às versões principais em que as instâncias estão em execução. O suporte estendido é oferecido por três anos. É possível usar esse tempo para planejar, testar e fazer o upgrade das instâncias para uma versão principal com suporte regular. Para mais informações sobre como realizar um upgrade da versão principal, consulte Fazer upgrade da versão principal do banco de dados no local e Fazer upgrade da versão principal do servidor de um cluster migrando dados.
Para mais informações sobre o suporte estendido, consulte Suporte estendido no AlloyDB.
Suspensão de uso
Depois que o suporte estendido de uma versão principal é encerrado, o AlloyDB descontinua essa versão. Quando o Google Cloud planeja encerrar o suporte estendido para uma versão principal do PostgreSQL,o Google Cloud fornece o seguinte aos proprietários do projeto:
- Avisos de fim de suporte, enviados com pelo menos 12 meses de antecedência, no final do segundo ano de suporte estendido.
- Ferramentas e documentação para minimizar a interrupção do upgrade.
Qualquer cluster do AlloyDB que ainda estiver executando a versão principal descontinuada do banco de dados no final do período de suporte estendido será atualizado automaticamente para a versão padrão.
Cronograma de suporte à versão principal
A tabela a seguir mostra as datas em que o suporte do AlloyDB para versões compatíveis se tornou em disponibilidade geral (GA):
Versão principal compatível com PostgreSQL |
Data de início do suporte regular do AlloyDB |
Data de disponibilidade geral do suporte à versão do AlloyDB Omni |
Data de início do suporte estendido do AlloyDB |
Data de descontinuação do AlloyDB |
|---|---|---|---|---|
PostgreSQL 18 |
18 de março de 2026 |
9 de abril de 2026 |
- |
- |
PostgreSQL 17 |
22 de setembro de 2025 |
15 de dezembro de 2025 |
1 de fevereiro de 2030 |
1 de fevereiro de 2033 |
PostgreSQL 16 |
23 de outubro de 2024 |
8 de abril de 2025 |
1 de fevereiro de 2029 |
1 de fevereiro de 2032 |
PostgreSQL 15 |
19 de janeiro de 2024 |
11 de outubro de 2023 |
1 de fevereiro de 2028 |
1 de fevereiro de 2031 |
PostgreSQL 14 |
12 de dezembro de 2022 |
Não relevante |
1 de fevereiro de 2027 |
1 de fevereiro de 2030 |
Dependências de versão para recursos do AlloyDB
Alguns recursos do AlloyDB podem exigir uma versão principal de compatibilidade com o PostgreSQL para serem executados em uma instância do AlloyDB. Os requisitos de versão mínima para os recursos estão documentados.
Suporte à versão secundária
O AlloyDB e o AlloyDB no Distributed Cloud visam lançar suporte de compatibilidade para uma nova versão secundária do PostgreSQL a cada trimestre. Essas atualizações incluem correções de bugs e de segurança. O cronograma de lançamentos pode variar dependendo da necessidade de outras correções de bugs.
Depois que o AlloyDB lança suporte para uma nova versão secundária do PostgreSQL,o Google Cloud aplica automaticamente essa atualização a todas as instâncias. Essas atualizações são propagadas durante um lançamento de manutenção subsequente. Para mais informações sobre a manutenção automática do AlloyDB, consulte Sobre a manutenção.
Por exemplo, se o AlloyDB lançar suporte para uma nova versão secundária do PostgreSQL 17, um cluster configurado com compatibilidade com o PostgreSQL 17 terá todas as instâncias atualizadas para essa nova versão secundária durante uma operação de manutenção programada subsequente.
Quando você cria uma instância do AlloyDB, ela executa a versão secundária mais recente com suporte na versão principal do PostgreSQL.
Suporte a versões principais e secundárias
O AlloyDB é compatível com as seguintes versões do banco de dados PostgreSQL:
Versão compatível com PostgreSQL |
AlloyDB |
|---|---|
PostgreSQL 18 |
18.3 |
PostgreSQL 17 (padrão) |
17.9 |
|
PostgreSQL 16 |
16.13 |
PostgreSQL 15 |
15.17 |
PostgreSQL 14 |
14.22 |
Compatibilidade com o PostgreSQL 18
Antes de usar o PostgreSQL 18 como versão do banco de dados, considere o seguinte:
- A replicação lógica do servidor em espera não é compatível.
Compatibilidade com o PostgreSQL 17
Antes de usar o PostgreSQL 17 como versão do banco de dados, considere o seguinte:
- A replicação lógica do servidor em espera não é compatível.
Compatibilidade com o PostgreSQL 16
Antes de usar o PostgreSQL 16 como versão do banco de dados, considere o seguinte:
- A replicação lógica do servidor em espera não é compatível.
Atualizações de segurança
Quando a comunidade do PostgreSQL lança versões secundárias com correções de segurança, a equipe de segurança do AlloyDB as analisa para verificar a gravidade e o impacto.
No AlloyDB para PostgreSQL, as correções críticas são retroportadas, e os clusters são atualizados como parte de um lançamento de manutenção subsequente.O Google Cloud tem como objetivo aplicar patches críticos em até um mês.
As correções menos graves são incluídas em upgrades de versões secundárias futuras. Isso garante que os clusters estejam sempre atualizados com as correções de segurança mais recentes e protegidos contra possíveis ataques.