Fin du support de PostgreSQL 14 le 12 novembre 2026 : vers quelle version migrer

PostgreSQL 14 reçoit sa dernière version mineure le 12 novembre 2026. Après cette date, la communauté PostgreSQL ne publie plus aucun correctif pour cette version, ni de sécurité ni de bogue. Ce guide donne les dates exactes, ce que la fin du support change, les échéances chez AWS, Azure et Google Cloud, la version vers laquelle migrer et la façon de le faire sans mauvaise surprise.

Il s’adresse aux dirigeants techniques, aux DSI et aux responsables d’applications dont une base de données tourne encore en PostgreSQL 14, sur leurs propres serveurs ou chez un hébergeur. La mise à jour des bases de données fait partie de notre offre infra, DevOps et sécurité web.

Quand le support de PostgreSQL 14 s’arrête-t-il ?

Le support communautaire de PostgreSQL 14 s’arrête le 12 novembre 2026, jour de sa dernière version mineure. La règle est connue depuis la sortie de la version, le 30 septembre 2021 : le PostgreSQL Global Development Group maintient chaque version majeure pendant cinq ans, puis publie une dernière version mineure, après laquelle la version n’est plus supportée.

D’ici là, chaque version majeure maintenue reçoit au moins tous les trois mois une version mineure, qui corrige des bogues, des failles de sécurité et des problèmes de corruption de données. La dernière version mineure de PostgreSQL 14 publiée à ce jour est la 14.24, du 13 août 2026 ; la suivante, prévue le 12 novembre 2026, sera la dernière.

PostgreSQL 13 n’est déjà plus maintenue depuis le 13 novembre 2025 : une base encore en version 13, ou plus ancienne, est dans la même situation, avec un an d’avance.

Que se passe-t-il après la fin du support de PostgreSQL 14 ?

Après le 12 novembre 2026, une base PostgreSQL 14 continue de fonctionner normalement, mais aucune faille découverte ensuite ne sera plus corrigée pour elle. Rien ne s’arrête le 13 novembre : c’est le risque qui grandit, à mesure que des failles corrigées dans les versions 15 à 18 restent ouvertes en version 14.

La communauté le dit dans sa politique de versions : elle juge moins risqué d’appliquer les versions mineures que de rester sur une ancienne, et recommande de toujours utiliser la dernière version mineure de sa version majeure. Une version qui n’en reçoit plus sort de ce cadre.

• La sécurité. Une faille publiée après le 12 novembre 2026 qui touche aussi la version 14 restera ouverte, sauf support étendu d’un hébergeur.
• Les outils autour de la base. Les nouveautés ne visent plus les versions retirées : chez Azure, par exemple, les nouvelles extensions ne sont pas proposées pour une version que la communauté a retirée.
• Les exigences de vos clients et de vos audits. Si un contrat, un client ou un audit de sécurité exige des composants maintenus, une base en version 14 devient un écart à justifier.
• La migration elle-même. Plus l’écart grandit entre la version en place et la version cible, plus il y a de notes de version à lire et de changements à tester.

La logique est la même que pour un langage arrivé en fin de vie : notre article sur la fin du support de PHP 8.2 décrit la même démarche côté code.

PostgreSQL 14 chez AWS, Azure ou Google Cloud : quelles dates ?

Chez les grands hébergeurs de bases de données gérées, PostgreSQL 14 reste couvert quelques semaines de plus que dans la communauté, puis passe à un support étendu, payant chez AWS et Google Cloud. Voici les dates relevées le 4 novembre 2026 dans leurs documentations :

Azure précise qu’une fois une version retirée par la communauté, il cesse d’appliquer les correctifs du moteur de base de données, tout en continuant à maintenir le système et l’infrastructure. Il se réserve aussi d’arrêter un serveur exposé à une faille critique, le temps de sa mise à niveau.

Le support étendu achète du temps, pas une solution : il se paie tant que la base reste en version 14, et il s’arrête lui aussi. Pour une base installée sur vos propres serveurs ou chez un hébergeur classique, la date à retenir reste le 12 novembre 2026 : après elle, plus aucun correctif public.

Vers quelle version de PostgreSQL migrer ?

Pour quitter PostgreSQL 14, la version cible à privilégier est PostgreSQL 18 : c’est la plus récente version stable, sortie le 25 septembre 2025, et elle sera maintenue jusqu’au 14 novembre 2030.

• PostgreSQL 18, le choix par défaut. Maintenue jusqu’au 14 novembre 2030. Son outil pg_upgrade conserve désormais les statistiques de l’optimiseur, ce qui réduit le travail après la migration (les statistiques étendues, elles, sont à recalculer).
• PostgreSQL 17, si un composant l’impose. Quand une extension, un pilote ou un outil dont l’application dépend n’est pas encore validé en version 18. Maintenue jusqu’au 8 novembre 2029.
• PostgreSQL 15 ou 16, à éviter comme cible. La 15 s’arrête le 11 novembre 2027, la 16 le 9 novembre 2028 : la même migration serait à refaire dans un ou deux ans.
• PostgreSQL 19, pas tout de suite. Sa première version candidate est sortie le 15 octobre 2026 et sa sortie officielle est prévue le 19 novembre 2026, sauf report. Une version tout juste sortie se teste avant de porter une production : pour une migration à mener maintenant, la 18 reste le choix raisonnable.

La documentation de PostgreSQL le permet : on passe d’une version majeure à une autre sans installer les versions intermédiaires, à condition de lire les notes de version de chaque version sautée, soit les versions 15, 16, 17 et 18 pour un passage de 14 à 18.

Comment migrer de PostgreSQL 14 vers PostgreSQL 18 ?

Une migration de version majeure ne se fait pas comme une mise à jour mineure : le format des fichiers de données change. Il faut soit exporter puis réimporter la base, soit convertir ses fichiers avec pg_upgrade, soit passer par la réplication logique. Le choix dépend surtout de la taille de la base et de l’interruption acceptable.

Chez AWS, Azure ou Google Cloud, la mise à niveau de version majeure se lance depuis le service de l’hébergeur, mais la préparation et les tests restent les mêmes. Les étapes, dans l’ordre :

• Faire l’inventaire. Version exacte, taille des bases, extensions installées et leur version, pilotes utilisés par l’application, scripts de sauvegarde et de supervision. Un audit rapide de l’existant répond à ces questions.
• Choisir la version cible et la méthode. Vérifier que chaque extension existe pour la version cible : pg_upgrade ne peut pas contrôler la compatibilité des modules externes.
• Préparer un environnement de recette. Une copie de la base en version 18, sur laquelle l’application tourne avec ses tests. Si la copie contient des données personnelles, lisez notre article sur les données de test et le RGPD.
• Lancer pg_upgrade en mode contrôle. L’option --check ne modifie aucune donnée et liste les ajustements nécessaires ; elle peut tourner pendant que l’ancien serveur fonctionne.
• Tester l’application. Les parcours critiques, les traitements planifiés, les sauvegardes et leur restauration, et le temps de réponse des requêtes les plus lourdes.
• Sauvegarder et prévoir le retour arrière. Une sauvegarde complète, restaurée au moins une fois, et une procédure écrite pour revenir en arrière si la bascule échoue.
• Migrer en production, puis surveiller. Dans une fenêtre annoncée aux utilisateurs ; ensuite, recalculer les statistiques qui n’ont pas été reprises, mettre à jour les extensions, et suivre les journaux et les temps de réponse.

Qu’est-ce qui change entre PostgreSQL 14 et PostgreSQL 18 ?

Les notes de version des versions 15 à 18 listent chacune leurs incompatibilités. Quatre d’entre elles touchent l’exploitation courante d’une base : les droits, les sauvegardes, le stockage et les mots de passe.

• Les droits sur le schéma public (version 15). Par défaut, les utilisateurs ne peuvent plus créer d’objets dans le schéma public d’une nouvelle base. Une base migrée garde ses droits d’origine, mais une base créée après la migration suit la nouvelle règle : un script d’installation qui crée des tables avec un compte qui n’est pas propriétaire de la base peut échouer.
• La sauvegarde exclusive (version 15). L’ancien mode de sauvegarde exclusif est supprimé, et les fonctions pg_start_backup() et pg_stop_backup() deviennent pg_backup_start() et pg_backup_stop(). Les scripts de sauvegarde maison qui les appellent sont à revoir.
• Les sommes de contrôle des données (version 18). Un nouveau serveur est désormais créé avec les sommes de contrôle activées. pg_upgrade exige le même réglage des deux côtés : il faut créer le serveur cible avec l’option --no-data-checksums si l’ancien n’en avait pas, ou les activer d’abord sur l’ancien.
• Les mots de passe MD5 (version 18). L’authentification par mot de passe MD5 est dépréciée et sera retirée dans une version future ; la version 18 affiche un avertissement à chaque mot de passe MD5 défini. C’est le moment de passer les comptes à SCRAM-SHA-256.

Lisez aussi la section « Migration » des notes des versions 16 et 17 : chacune liste ses propres changements de comportement, à confronter aux requêtes et aux réglages de votre application. Une base restée longtemps sans mise à niveau cache souvent d’autres retards, côté code comme côté infrastructure : c’est une part de la dette technique.

Questions fréquentes

PostgreSQL 14 : fixez maintenant la date de la migration

Le 12 novembre 2026 ne casse rien, mais il ouvre une période où chaque faille découverte reste ouverte sur PostgreSQL 14. La décision tient en trois points : la version cible (18, ou 17 si un composant l’impose), la méthode, et une date de bascule fixée après une répétition en recette.

L’équipe iones prépare et mène des migrations de bases PostgreSQL, de l’inventaire à la mise en production, dans le cadre de son offre infra, DevOps et sécurité web, et les tient à jour dans la durée avec la maintenance applicative. Pour faire le point sur vos bases, écrivez-nous.