Supabase Postgres 14 arrive en fin de support : checklist avant l’auto-upgrade
L’échéance est maintenant opérationnelle. Supabase arrête le support de Postgres 14 le 1er juillet 2026. Les projets encore sur une version dépréciée seront automatiquement migrés vers la version disponible la plus récente; ceux qui utilisent des extensions non prises en charge peuvent être mis en pause et ne plus servir de trafic.
Pourquoi agir maintenant
PostgreSQL upstream indique une fin de vie de Postgres 14 au 12 novembre 2026. La date Supabase arrive donc plus tôt. C’est cohérent pour une plateforme managée, mais une équipe produit doit vérifier ses dépendances réelles avant cette date.
Official references to verify before acting: Supabase changelog, Supabase upgrade guide, and PostgreSQL 14 EOL notice.
Ce qui change
La documentation Supabase décrit l’upgrade in-place via `pg_upgrade` comme la voie recommandée pour de nombreux projets. Elle est généralement plus rapide que pause-and-restore, mais elle nécessite tout de même une fenêtre d’indisponibilité et des validations applicatives.
| 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. |
Signal communautaire
Les discussions communautaires mettent surtout en avant les extensions, `pg_cron`, les rôles personnalisés, la réplication logique et les intégrations BI/ETL. Elles ne remplacent pas les sources officielles, mais elles montrent les zones de friction.
Community migration discussions are useful as narrative signals, but the operational policy should be checked against Supabase’s official changelog and docs.
Impact dev et ops
Commencez par `select version();`, puis listez extensions, rôles, jobs, replication slots et clients externes. Testez dans un environnement de staging ou une copie restaurée, préparez vos smoke tests et fixez les critères de rollback avant la production.
Actions immédiates
Upgrade readiness checklist
✓Exécuter et conserver `select version();`.
✓Auditer extensions, `pg_cron`, rôles et mots de passe.
✓Documenter replication slots et clients externes.
✓Tester l’upgrade en staging ou sur une copie.
✓Préparer les smoke tests auth, RLS, webhooks, jobs et admin.
✓Définir fenêtre, rollback et contact support.
Pour un petit projet, l’auto-upgrade peut suffire. Pour une application critique, le service managé exécute l’opération d’infrastructure, mais seul votre équipe connaît les contrats applicatifs à valider.
Risques et objections
Pour un petit projet, l’auto-upgrade peut suffire. Pour une application critique, le service managé exécute l’opération d’infrastructure, mais seul votre équipe connaît les contrats applicatifs à valider.