Supabase Postgres 14 acaba em breve: checklist antes do auto-upgrade

Dev

O prazo já virou assunto de operação. A Supabase encerra o suporte ao Postgres 14 em 1º de julho de 2026. Projetos ainda em versão depreciada serão atualizados automaticamente para a versão disponível mais recente; se houver extensões sem suporte, o projeto pode ser pausado e parar de servir tráfego.

01
Ver versão
02
Auditar extensões
03
Testar upgrade
04
Planejar janela
05
Validar
Fluxo operacional para tirar projetos Supabase do Postgres 14 antes de 1º de julho.

Por que olhar agora

O PostgreSQL upstream lista o EOL do Postgres 14 para 12 de novembro de 2026. A data da Supabase chega antes. Para uma plataforma gerenciada isso é compreensível, mas para times de produto exige inventário agora.

Official references to verify before acting: Supabase changelog, Supabase upgrade guide, and PostgreSQL 14 EOL notice.

O que mudou

A documentação da Supabase recomenda o in-place upgrade com `pg_upgrade` para muitos projetos. Ele costuma ser mais rápido que pausar e restaurar, mas ainda envolve downtime e validação da aplicação.

SurfaceExampleWhy it matters
Version`select version();`Do not rely on memory or project age.
Extensionsplv8, timescaledb, pgjwt, pg_cronExtension compatibility decides whether automation is safe.
Rolescustom login rolesPasswords for custom roles may need manual handling.
Replicationlogical replication slotsSlots may need to be recreated after upgrade.
Validationauth, RLS, jobs, webhooksApplication smoke tests catch what platform checks cannot.

Sinal da comunidade

Na comunidade, as preocupações aparecem em extensões, `pg_cron`, roles customizadas, replication slots e integrações externas. Não são fontes de política, mas mostram onde migrações reais tropeçam.

Community migration discussions are useful as narrative signals, but the operational policy should be checked against Supabase’s official changelog and docs.

Impacto em dev e operações

Comece com `select version();`, liste extensões, roles, jobs, replicação e clientes externos. Teste em staging ou em uma cópia restaurada, prepare smoke tests e defina critérios de rollback antes da produção.

O que fazer agora

Upgrade readiness checklist

Executar e registrar `select version();`.

Auditar extensões, `pg_cron`, roles e senhas.

Documentar replication slots e clientes externos.

Testar em staging ou cópia restaurada.

Preparar smoke tests de auth, RLS, webhooks, jobs e admin.

Definir janela, rollback e suporte.

Para projetos pequenos, o auto-upgrade pode bastar. Em produção, o serviço gerenciado executa a mecânica; o seu time ainda precisa validar o contrato da aplicação.

Riscos e contrapontos

Para projetos pequenos, o auto-upgrade pode bastar. Em produção, o serviço gerenciado executa a mecânica; o seu time ainda precisa validar o contrato da aplicação.

Fontes