PostgreSQL 14 va cesser d’être pris en charge en novembre 2026 : mise à niveau vers PostgreSQL 17 ou 18 ?

Évaluez PostgreSQL 17 en premier si la priorité est la compatibilité des extensions et la maîtrise du risque en production ; retenez PostgreSQL 18 seulement après validation de toute la pile et si une de ses fonctionnalités répond à un besoin démontré. La prise en charge de PostgreSQL 14 s’achève le 12 novembre 2026 : lancez l’évaluation sans attendre cette échéance, puis choisissez la cible à partir d’une migration répétée et d’un retour arrière vérifié.

Cet article s’adresse aux DBA qui exploitent encore PostgreSQL 14 et aux responsables des changements de version. Il concerne aussi les ingénieurs backend, les équipes data et les responsables SaaS qui doivent valider une migration avant de l’inscrire à leur calendrier de production.

Dernière mise à jour : 21 octobre 2026. Dates et versions vérifiées dans la politique officielle de prise en charge et les notes de publication PostgreSQL 18.6.

Le calendrier de maintenance fixe l’urgence, pas la version cible

La fin de prise en charge de PostgreSQL 14 n’empêche pas automatiquement une instance de démarrer. Elle marque la fin de la maintenance officielle de la branche : l’équipe ne doit donc pas confondre « la base fonctionne encore » avec « la base continue à recevoir les mises à jour attendues ». Maintenir l’ancienne version après l’échéance peut devenir une exception opérationnelle, mais ce n’est pas un plan de migration.

Les dates publiées par le projet permettent de comparer les fenêtres de maintenance :

• PostgreSQL 14.24 est pris en charge jusqu’au 12 novembre 2026.
• PostgreSQL 17.11 est pris en charge jusqu’au 8 novembre 2029.
• PostgreSQL 18.6 est pris en charge jusqu’au 14 novembre 2030.

Ces versions mineures et dates figurent dans la page officielle du cycle de vie PostgreSQL. Vérifiez la page à nouveau au moment d’établir le plan de changement : une version mineure plus récente peut être publiée, sans que cela change le choix entre les versions majeures.

PostgreSQL 18 a été publié le 25 septembre 2025, selon les notes de publication officielles de PostgreSQL 18. Sa fenêtre de maintenance plus longue que celle de PostgreSQL 17 est un facteur de décision, pas une preuve qu’il constitue la meilleure cible pour toute application. La question utile est celle de la prochaine migration que l’équipe pourra réellement préparer, valider et prendre en charge.

La version mineure doit aussi être distinguée de la version majeure. Passer de PostgreSQL 14.24 à une version mineure ultérieure de la même branche ne remplace pas la migration vers PostgreSQL 17 ou 18. Le processus de changement, les extensions nécessaires et la procédure de retour arrière doivent être préparés pour la version majeure visée, et non déduits d’une simple mise à jour de correctif.

La compatibilité de la pile départage PostgreSQL 17 et 18

Le numéro de version du serveur n’est qu’un élément de la pile. Avant de choisir une cible, l’équipe doit savoir si l’application, ses pilotes, les bibliothèques utilisées et les outils d’exploitation fonctionnent correctement avec cette cible. Une validation qui ne couvre que le démarrage du serveur laisse de côté les interactions susceptibles de casser les traitements réels.

Établissez un inventaire exploitable, plutôt qu’une liste de noms sans responsable :

• les applications qui ouvrent des connexions, leurs pilotes et leurs bibliothèques d’accès ;
• les pools de connexions et leurs paramètres, notamment les mécanismes de reprise et la gestion des sessions ;
• les extensions installées, leur version actuelle, leur usage et la disponibilité d’une version compatible avec la cible ;
• les outils de sauvegarde, de supervision, de réplication et de maintenance, ainsi que leurs propres prérequis ;
• les dépendances au système d’exploitation, aux paquets et aux procédures de déploiement.

Pour chaque extension, le contrôle doit être spécifique à l’environnement. Relevez son nom et sa version depuis l’instance, identifiez les objets ou traitements qui en dépendent, puis vérifiez les instructions de mise à niveau de son mainteneur et sa disponibilité pour la version cible. Le fait qu’une extension soit installable sur une machine de test ne confirme ni son comportement avec les données réelles, ni sa compatibilité avec les autres composants.

Les notes de publication de PostgreSQL 18 doivent être examinées pour repérer les changements susceptibles d’affecter les applications, les extensions et les outils. Il ne faut pas transformer une mention générale dans ces notes en garantie de compatibilité pour un environnement donné. Si l’équipe ne peut pas confirmer l’état d’une extension critique, ce point reste un risque ouvert ; il doit être résolu avant la décision de bascule.

La décision entre les deux versions suit des critères vérifiables

Utilisez cette grille avant de réserver une fenêtre de production. Les cases doivent refléter des validations réalisées, pas des hypothèses ou des déclarations générales de compatibilité.

• [ ] Applications et pilotes validés sur PostgreSQL 18. Si ce contrôle échoue ou reste incomplet, choisissez PostgreSQL 17 comme cible à évaluer en premier.
• [ ] Chaque extension critique dispose d’une version compatible et d’une procédure de mise à niveau documentée. Si une dépendance essentielle n’est pas vérifiée, ne retenez pas PostgreSQL 18 pour la bascule ; confirmez d’abord la compatibilité sur PostgreSQL 17 ou résolvez le blocage.
• [ ] Une fonctionnalité précise de PostgreSQL 18 répond à un besoin mesuré. Si aucun besoin concret n’est identifié, la fenêtre de maintenance plus longue de PostgreSQL 18 ne suffit pas, à elle seule, à justifier le risque supplémentaire de changement.
• [ ] La migration vers la cible a été répétée sur un environnement représentatif. Si la répétition n’a pas couvert les traitements importants, gardez la cible au stade d’évaluation et n’approuvez pas encore la bascule.
• [ ] La restauration et les critères de retour arrière ont été testés. Si l’ancienne instance ne peut pas être rétablie selon une procédure éprouvée, reportez le changement de production.

La règle de décision est donc la suivante : si toutes les cases sont validées et qu’une fonctionnalité de la version 18 est nécessaire, retenez PostgreSQL 18 ; si la compatibilité de l’application ou d’une extension importante reste incertaine, privilégiez PostgreSQL 17 comme cible d’évaluation ; si la répétition ou la restauration échoue, ne basculez pas encore sur l’une ou l’autre. PostgreSQL 17 n’est pas une destination universelle, pas plus que PostgreSQL 18 n’est automatiquement le meilleur choix. La cible doit pouvoir être exploitée et restaurée par l’équipe, pas seulement démarrer sur un serveur de test.

Le chemin de migration se choisit d’après l’arrêt et le retour arrière

Une migration majeure n’est pas le remplacement de fichiers exécutables. Elle implique une procédure adaptée aux données, aux extensions et au niveau d’interruption acceptable par le service. Les voies disponibles ne présentent pas les mêmes exigences ; le choix doit être justifié par une répétition, pas par une durée supposée.

• pg_upgrade convient à une mise à niveau sur place lorsque les conditions documentées sont satisfaites et que l’équipe peut planifier la phase de bascule. Avant l’intervention, utilisez son contrôle préalable avec pg_upgrade --check dans un environnement de répétition. La documentation officielle de pg_upgrade décrit les prérequis et limites à vérifier pour la procédure choisie.
• La sauvegarde logique suivie d’une restauration permet de reconstruire la base sur la cible à partir d’une exportation. Cette voie est facile à expliquer et à tester, mais le temps de restauration dépend du volume, des objets, des index et des ressources disponibles. N’annoncez pas de durée avant de l’avoir mesurée sur une copie représentative.
• La réplication logique peut organiser une transition avec une synchronisation vers le nouveau serveur, sous réserve de vérifier les objets et fonctions qui ne sont pas répliqués comme attendu, ainsi que les contraintes propres à l’application. Consultez le guide officiel de mise à niveau par réplication logique avant de retenir cette voie.

La documentation générale de mise à niveau sert à confronter ces options aux contraintes du projet. La taille de la base ne suffit pas pour choisir : une base relativement modeste peut avoir des extensions sensibles ou des opérations applicatives difficiles à interrompre, tandis qu’une base plus volumineuse peut disposer d’une fenêtre de maintenance planifiée et d’une procédure de bascule éprouvée.

Pour estimer l’interruption, chronométrez chaque phase sur une restauration ou une copie représentative : préparation, vérifications, transfert ou mise à niveau, contrôles postérieurs, puis décision de remise en service. La mesure doit inclure le temps nécessaire aux tests métier et aux vérifications de réplication, pas seulement le temps passé par l’outil de migration. Si la répétition dépasse la fenêtre disponible, changez de méthode ou redéfinissez la fenêtre ; ne réduisez pas les contrôles pour faire tenir artificiellement le plan.

Le retour arrière doit être écrit avant la bascule. Définissez les critères qui imposent l’arrêt de la procédure, la personne autorisée à décider et la méthode de restauration de l’ancienne instance. Précisez aussi à quel moment les écritures sur la nouvelle base rendent un simple retour à l’ancienne version risqué ou impossible sans réconciliation. Une migration sans retour arrière testable repose sur l’espoir que tout se passera bien, pas sur une procédure opérationnelle.

Une fonctionnalité récente ne vaut que si elle répond à un besoin

PostgreSQL 18 apporte des changements décrits dans ses notes de publication, mais leur présence ne constitue pas à elle seule une raison de migrer vers cette version. Pour une base de production, l’équipe doit relier la fonctionnalité recherchée à un symptôme ou à une exigence existante : opération trop coûteuse, besoin applicatif non couvert ou contrainte d’exploitation clairement documentée.

Avant d’en faire un argument de sélection, formulez le résultat attendu et la façon de l’observer. Préparez un jeu de requêtes représentatif, les traitements batch concernés, les opérations de maintenance et les scénarios de reprise. Comparez les résultats sur les mêmes données et avec des paramètres explicitement consignés. Les descriptions de performance dans les notes de publication ne remplacent pas une mesure sur la charge réelle ; cet article ne suppose donc aucun gain de débit ou de latence.

La validation doit aussi couvrir les comportements, pas seulement le temps d’exécution :

• les requêtes et transactions qui soutiennent les parcours essentiels de l’application ;
• les tâches planifiées, scripts et traitements de données ;
• les extensions et fonctions appelées indirectement par l’application ;
• les sauvegardes, la restauration et les contrôles après incident ;
• les alertes, tableaux de bord et outils d’administration utilisés au quotidien.

Si PostgreSQL 18 n’apporte pas de bénéfice identifié et que des dépendances restent à qualifier, PostgreSQL 17 peut être une cible plus maîtrisable. À l’inverse, si une fonction précise est nécessaire et que toute la chaîne est validée, l’équipe peut retenir PostgreSQL 18 en consignant les résultats des tests et les risques résiduels. Dans les deux cas, la décision doit être compréhensible par les personnes qui approuveront et exploiteront le changement.

La capacité de restauration compte autant que la capacité du serveur

Avant de migrer, estimez l’espace nécessaire aux données existantes, aux fichiers temporaires de migration, aux index reconstruits et aux sauvegardes conservées pendant la transition. La méthode retenue détermine ce qui doit coexister au même moment. Une taille de disque qui paraît suffisante pour la base en fonctionnement peut ne pas l’être pour une migration qui conserve simultanément une source, une cible et une copie de sauvegarde.

Évaluez aussi les besoins en mémoire à partir de la charge observée et des processus qui partagent la machine. La version cible ne justifie pas, à elle seule, une valeur fixe de mémoire ou un dimensionnement standard. Mesurez les besoins du serveur et de ses services annexes, puis vérifiez que les contraintes de ressources ne dégradent pas la fenêtre de migration ni les contrôles après bascule.

La sauvegarde doit être stockée à l’extérieur de la machine qui héberge la base et son rétablissement doit être testé. La documentation officielle sur la sauvegarde et la restauration PostgreSQL décrit les approches disponibles ; l’équipe doit retenir celle qui permet de restaurer ses données, ses configurations et les éléments nécessaires à la reprise de service. Une sauvegarde présente mais jamais restaurée ne prouve pas qu’un retour arrière est possible.

Enfin, ne confondez pas redondance locale et sauvegarde. Si le stockage ne comporte pas de RAID matériel, prévoyez explicitement une redondance logicielle ou une réplication adaptée à votre architecture, tout en conservant une sauvegarde indépendante hors machine. Un miroir peut aider face à la défaillance d’un disque ; il ne remplace pas une copie de récupération contre une erreur logique, une suppression ou une corruption propagée.

Si la migration s’accompagne d’un changement d’hébergement, comparez les besoins réels de la base avec les options publiées sur la page des offres de serveurs. Le choix doit prendre en compte la mémoire disponible, le stockage, les sauvegardes et la manière dont l’équipe administrera le système ; une configuration ne peut pas être recommandée sans connaître la taille de la base et les exigences de service.

Questions fréquentes

PostgreSQL 14 peut-il rester en service après la fin de prise en charge ?

Techniquement, une base déjà installée ne s’arrête pas automatiquement à cette date. En revanche, la branche ne reçoit plus les mises à jour officielles prévues par sa politique de prise en charge, ce qui augmente le risque d’exposition à des défauts corrigés dans les versions maintenues. Il faut donc planifier la migration ou documenter une exception temporaire avec des mesures compensatoires.

Quelle cible choisir pour quitter PostgreSQL 14 ?

PostgreSQL 17 est le choix par défaut lorsque la priorité est de limiter le risque de changement et de confirmer la compatibilité de la pile existante. PostgreSQL 18 devient préférable si l’application, les pilotes et chaque extension sont validés sur cette version et si une fonctionnalité précise répond à un besoin réel. La répétition de migration doit départager les deux options.

Que vérifier pour les extensions avant PostgreSQL 18 ?

Établissez l’inventaire des extensions installées, de leurs versions et de leur rôle dans les applications, puis vérifiez séparément la disponibilité d’une version compatible avec PostgreSQL 18, son mode d’installation et les éventuelles étapes de mise à niveau. Contrôlez aussi les pilotes, les composants de supervision et les outils de sauvegarde : une extension disponible dans un environnement ne prouve pas sa compatibilité partout.

Quelle durée d’arrêt prévoir avec pg_upgrade ?

Aucune durée fiable ne peut être déduite du seul nom de l’outil. L’interruption dépend de la taille et de la disposition des données, des vérifications nécessaires, des index, du stockage et des opérations postérieures à la migration. Mesurez-la pendant une répétition sur un environnement représentatif, puis ajoutez le temps de validation et le délai nécessaire pour décider d’un retour arrière.

Préparez la bascule avant de choisir l’hébergement

La prochaine action est de dresser l’inventaire des dépendances, de choisir une cible provisoire et de réaliser une migration complète en environnement isolé, restauration comprise. Si l’hébergement actuel impose des limites de mémoire, une concurrence de ressources entre voisins ou des coûts de stockage difficiles à prévoir, comparez-les à une machine physique dédiée AMD pour un service qui doit fonctionner durablement. Ce choix ne supprime ni les mises à niveau ni les obligations de sauvegarde ; il peut toutefois convenir lorsque l’équipe veut disposer d’une machine réservée à sa charge et maîtriser son environnement système.

Pour examiner cette option, consultez les offres disponibles, puis vérifiez les modalités d’accès et d’administration dans le guide d’accès au serveur. Le choix final doit rester conditionné par les exigences de capacité, la procédure de restauration et la compatibilité validée pour PostgreSQL 17 ou PostgreSQL 18, et non par le seul calendrier de fin de prise en charge.

Questions fréquentes