PostgreSQL 14 en fin de vie le 12 novembre 2026, PostgreSQL 19 en approche : que faire de vos bases

Deux échéances se croisent pour PostgreSQL en fin d’année 2026. PostgreSQL 14 reçoit sa dernière mise à jour le 12 novembre 2026, date de sa fin de vie officielle. Et PostgreSQL 19 a publié sa première version candidate le 15 octobre 2026, avec une disponibilité générale planifiée au 19 novembre 2026. Si vos applications tournent encore sur PostgreSQL 14, c’est le moment de choisir la version cible.

PostgreSQL 14 : ce que signifie la fin de vie

Le projet PostgreSQL maintient chaque version majeure pendant cinq ans après sa sortie. PostgreSQL 14, sorti le 30 septembre 2021, arrive donc au bout : la mise à jour mineure du 12 novembre 2026 est la dernière prévue.

Après cette date, plus aucun correctif de bogue ni de sécurité. La base continue de fonctionner, mais une faille découverte ensuite ne sera pas corrigée pour cette branche. Les distributions Linux ou les hébergeurs peuvent prolonger un support de leur côté, mais ce n’est plus le projet officiel qui s’en charge.

Une autre conséquence, plus discrète : les frameworks abandonnent eux aussi les anciennes versions. Django 6.1, sorti le 5 août 2026, exige déjà PostgreSQL 15 ou plus récent.

Le calendrier des versions supportées

PostgreSQL 13 n’est plus supporté depuis le 13 novembre 2025.

PostgreSQL 19 : les nouveautés annoncées

La première bêta, publiée le 4 juin 2026, détaillait les apports de cette version. Les plus utiles au quotidien :

Pour les développeurs

• GROUP BY ALL : regroupe automatiquement par toutes les colonnes qui ne sont ni des agrégats ni des fonctions de fenêtrage. Fini les listes de colonnes recopiées.
• INSERT ... ON CONFLICT DO SELECT ... RETURNING : un upsert qui renvoie aussi les lignes en conflit.
• FOR PORTION OF dans UPDATE et DELETE, pour les données temporelles.
• ALTER TABLE ... MERGE PARTITIONS et SPLIT PARTITIONS pour réorganiser des tables partitionnées sur place.
• SQL/PGQ : des requêtes de graphe de propriétés avec la syntaxe standard SQL.
• WAIT FOR LSN : une session peut attendre qu’une réplique ait rejoué une écriture avant de la lire, utile pour lire ses propres écritures sur un réplica.

Pour l’exploitation

• REPACK, avec une option CONCURRENTLY, pour reconstruire une table avec moins de contraintes opérationnelles.
• Autovacuum parallèle (autovacuum_max_parallel_workers) et un nouveau système de priorisation des tables à nettoyer.
• Sommes de contrôle activables en ligne, sans redémarrage ni réinitialisation du cluster.
• Insertions jusqu’à deux fois plus rapides quand des clés étrangères doivent être vérifiées.
• Réplication logique des séquences, qui simplifie les montées de version en ligne.
• Nouvelles vues de supervision pg_stat_lock et pg_stat_recovery.

Pour la sécurité

• pg_hosts.conf permet de présenter différents certificats TLS selon le nom d’hôte demandé (SNI).
• Avertissements avant expiration des mots de passe, sept jours avant par défaut.
• L’authentification md5 affiche désormais un avertissement au client après connexion.

Les ruptures de compatibilité de PostgreSQL 19

• Le JIT est désactivé par défaut. Si certaines requêtes analytiques en bénéficiaient, il faudra le réactiver explicitement.
• default_toast_compression passe à lz4.
• L’authentification RADIUS est supprimée.
• vacuumdb --analyze-only analyse désormais par défaut les tables partitionnées.

La version candidate du 15 octobre 2026 corrige encore plusieurs points, notamment autour de REPACK (CONCURRENTLY) et de l’autovacuum parallèle. L’annonce prévoyait une seconde version candidate le 12 novembre 2026, le jour de la mise à jour mineure de toutes les branches, puis la version finale le 19 novembre 2026.

Quelle version viser ?

Vous êtes sur PostgreSQL 14 (ou plus ancien)

Ne visez pas PostgreSQL 19 dès sa sortie pour une base de production. Les premières versions mineures d’une majeure corrigent souvent des défauts découverts par les premiers utilisateurs. PostgreSQL 17 ou 18 sont des cibles plus sûres : elles sont éprouvées et supportées jusqu’en 2029 et 2030.

Vous êtes sur 15 à 18

Pas d’urgence. PostgreSQL 15 reste supporté jusqu’au 11 novembre 2027 : programmez sa migration en 2027. Pour 19, testez-le sur une copie de votre base, puis attendez une ou deux versions mineures avant la production.

Comment migrer sans mauvaise surprise

1. Choisissez la méthode. Une montée de version majeure passe par pg_upgrade (rapide, sur le même serveur) ou par pg_dump / pg_restore (plus lent, mais plus souple). Pour une coupure minimale, la réplication logique reste l’option la plus fine.
2. Sauvegardez et testez la restauration avant toute opération. Une sauvegarde jamais restaurée n’est pas une sauvegarde.
3. Vérifiez vos extensions (PostGIS, pgvector, etc.) : elles doivent exister pour la version cible.
4. Contrôlez vos pilotes et ORM : un pilote trop ancien peut refuser une version récente du serveur.
5. Recalculez les statistiques après migration (ANALYZE) pour que le planificateur retrouve de bons plans.
6. Mesurez : comparez les temps de réponse de vos requêtes critiques avant et après.

Si vous exportez des données pour vos tests, notre convertisseur CSV vers JSON aide à préparer des jeux d’essai lisibles.

Sources

• PostgreSQL Global Development Group, « Versioning Policy » : https://www.postgresql.org/support/versioning/
• PostgreSQL Global Development Group, « PostgreSQL 19 RC 1 Released! », 15 octobre 2026 : https://www.postgresql.org/about/news/postgresql-19-rc-1-released-3409/
• PostgreSQL Global Development Group, « PostgreSQL 19 Beta 1 Released! », 4 juin 2026 : https://postgresql.org/about/news/postgresql-19-beta-1-released-3313/
• Django Software Foundation, « Django 6.1 release notes », 5 août 2026 : https://docs.djangoproject.com/en/stable/releases/6.1/