Le compte à rebours a commencé pour PostgreSQL 14. Selon la politique de versions publiée par le projet PostgreSQL, cette branche sortie le 30 septembre 2021 recevra sa toute dernière mise à jour le 12 novembre 2026. Passé cette date, plus aucun correctif, ni de bug ni de sécurité, ne sera publié par la communauté. Pour les équipes qui exploitent encore des bases en version 14, il reste trois semaines pour planifier la suite.
Les points :
Ce que signifie concrètement la fin de support #
Le projet PostgreSQL maintient chaque version majeure pendant cinq ans. La page de versions liste aujourd’hui la 14.24 comme dernière version mineure de la branche, et fixe sa date de « final release » au 12 novembre 2026. Cette date coïncide avec la prochaine vague de mises à jour mineures inscrite sur la feuille de route des développeurs, qui prévoit des publications le deuxième jeudi de février, mai, août et novembre.
Autrement dit, la mise à jour du 12 novembre sera la dernière pour la 14. Une base qui continue de tourner sur cette version ne cessera pas de fonctionner du jour au lendemain. En revanche, toute faille découverte ensuite restera ouverte, et les hébergeurs ou distributions qui suivent le calendrier communautaire risquent de retirer progressivement leurs paquets.
À lire Requête SQL : Guide Complet Bases de Données
Les versions qui restent maintenues
D’après la même page, la 15 est suivie jusqu’au 11 novembre 2027, la 16 jusqu’au 9 novembre 2028, la 17 jusqu’au 8 novembre 2029 et la 18, sortie le 25 septembre 2025, jusqu’au 14 novembre 2030. Migrer vers la 15 ne fait donc gagner qu’un an : pour un projet qui n’aime pas changer de version souvent, viser la 17 ou la 18 a davantage de sens.
PostgreSQL 19 arrive dans la foulée #
Le calendrier tombe au même moment que la sortie de la prochaine version majeure. L’annonce de la release candidate du 15 octobre fixe la disponibilité générale de PostgreSQL 19 au 19 novembre 2026, avec une seconde release candidate prévue le 12 novembre, sauf problème découvert d’ici là. Le projet rappelle qu’une version candidate n’est pas destinée à la production.
La question se pose donc pour beaucoup d’équipes : sauter directement de la 14 à la 19, ou passer par la 18, déjà éprouvée ? Une version majeure toute neuve mérite généralement quelques versions mineures avant d’accueillir des données critiques. Sauf besoin précis, la 18 reste le choix prudent pour une migration à faire avant la fin de l’année.
Les nouveautés qui pourraient faire attendre
Les notes de version de PostgreSQL 19 mettent en avant une commande REPACK qui récupère l’espace disque et réorganise les tables, avec une variante REPACK (CONCURRENTLY) qui ne bloque ni les lectures ni les écritures. On y trouve aussi l’autovacuum parallèle des index, la réplication logique des séquences et la possibilité d’activer la réplication logique sans redémarrage quand wal_level vaut replica.
À lire SQL LIKE : Guide Complet & Exemples Pratiques 2026
Les mêmes notes listent plusieurs ruptures à vérifier avant de migrer : standard_conforming_strings est désormais toujours activé, l’authentification RADIUS disparaît, le JIT est désactivé par défaut, et max_locks_per_transaction passe de 64 à 128 par défaut, avec un nouveau mode de calcul. Des dumps anciens réalisés avec standard_conforming_strings à off ne se rechargeront pas correctement.
Préparer la migration depuis la 14 #
Changer de version majeure ne se fait pas par une simple mise à jour de paquet. La documentation officielle sur la mise à niveau décrit trois voies : un export et une restauration avec pg_dumpall, l’outil pg_upgrade, ou la réplication logique vers un nouveau serveur.
Le choix dépend surtout du temps d’arrêt acceptable. L’export complet est le plus simple à comprendre mais le plus long sur une grosse base. pg_upgrade, notamment en mode lien, réduit fortement l’interruption mais demande les deux versions installées sur la même machine. La réplication logique permet de basculer avec une coupure de quelques instants, au prix d’une préparation plus lourde.
Un ordre de marche raisonnable
Avant toute chose, inventorier les instances qui tournent encore en 14, y compris les bases oubliées des environnements de recette et les conteneurs figés sur une ancienne image. Ensuite, restaurer une copie récente sur la version cible et faire tourner la suite de tests de l’application : c’est là que remontent les requêtes qui dépendaient d’un comportement disparu, comme une fonction JSON qui renvoie désormais un tableau vide au lieu de NULL dans la 19.
À lire SQL requête : Guide bases données
Il faut aussi vérifier les extensions installées. Chacune doit exister dans une version compatible avec la cible, faute de quoi pg_upgrade refusera de continuer. Enfin, prévoir un retour arrière : garder l’ancien cluster intact tant que la nouvelle version n’a pas tourné quelques jours en production.
Et chez les hébergeurs ? #
Les offres de bases managées suivent en général le calendrier communautaire, avec parfois un support étendu payant. Chaque fournisseur publie ses propres dates : il vaut mieux consulter la console de son hébergeur dès maintenant que découvrir une montée de version forcée au mauvais moment.
Trois semaines, c’est court pour une base critique, mais suffisant pour lancer l’inventaire, choisir la version cible et caler une fenêtre de migration. La mise à jour mineure du 12 novembre pourra au passage servir de dernier filet de sécurité pour les instances qui n’auront pas encore basculé.
