Supabase Postgres 14 finisce presto: checklist prima dell’auto-upgrade
La scadenza è ormai operativa. Supabase termina il supporto a Postgres 14 il 1 luglio 2026. I progetti ancora su una versione deprecata verranno aggiornati automaticamente alla versione disponibile più recente; se usano estensioni non più supportate, possono essere messi in pausa e non servire traffico.
Perché conta adesso
Il progetto PostgreSQL indica il 12 novembre 2026 come EOL di Postgres 14, quindi Supabase anticipa la scadenza. Per un servizio managed è comprensibile, ma per i team applicativi significa controllare subito le dipendenze.
Official references to verify before acting: Supabase changelog, Supabase upgrade guide, and PostgreSQL 14 EOL notice.
Cosa cambia
La documentazione Supabase consiglia spesso l’in-place upgrade con `pg_upgrade`. È in genere più veloce di pause and restore, ma resta un’operazione con downtime e richiede test applicativi.
| Surface | Example | Why it matters |
|---|---|---|
| Version | `select version();` | Do not rely on memory or project age. |
| Extensions | plv8, timescaledb, pgjwt, pg_cron | Extension compatibility decides whether automation is safe. |
| Roles | custom login roles | Passwords for custom roles may need manual handling. |
| Replication | logical replication slots | Slots may need to be recreated after upgrade. |
| Validation | auth, RLS, jobs, webhooks | Application smoke tests catch what platform checks cannot. |
Segnali dalla community
Le discussioni della community ruotano intorno a estensioni, `pg_cron`, ruoli custom, replication slot e integrazioni esterne. Non sono fonti ufficiali, ma indicano dove gli sviluppatori stanno trovando attrito.
Community migration discussions are useful as narrative signals, but the operational policy should be checked against Supabase’s official changelog and docs.
Impatto su sviluppo e operazioni
Parti da `select version();`, poi elenca estensioni, ruoli, job, replica logica e client esterni. Prova l’upgrade in staging o su una copia ripristinata, prepara smoke test e definisci criteri di rollback.
Cosa fare ora
Upgrade readiness checklist
✓Esegui e salva `select version();`.
✓Controlla estensioni, `pg_cron`, ruoli e password.
✓Documenta replication slot e client esterni.
✓Prova l’upgrade in staging o su copia.
✓Prepara smoke test per auth, RLS, webhook, job e admin.
✓Definisci finestra, rollback e contatto supporto.
Per un progetto piccolo l’auto-upgrade può bastare. In produzione, però, il provider gestisce la meccanica, mentre solo il team conosce le assunzioni dell’applicazione da validare.
Rischi e obiezioni
Per un progetto piccolo l’auto-upgrade può bastare. In produzione, però, il provider gestisce la meccanica, mentre solo il team conosce le assunzioni dell’applicazione da validare.