Principaux enseignements

•   PostgreSQL 12 a atteint sa fin de vie le 14 novembre 2024, et sa dernière version communautaire, la 12.22, a été publiée une semaine plus tard. La communauté ne proposera plus de correctifs de sécurité ni de corrections de bogues pour cette version.
•   La base de données continue de fonctionner après la fin de vie (EOL), et c'est là que réside le problème : les vulnérabilités CVE non corrigées s'accumulent discrètement jusqu'à ce qu'un audit de conformité ou une exploitation rende la situation urgente.
•   Vos options réalistes consistent soit à effectuer une mise à niveau vers une version prise en charge (18, 17, 16 ou 15), soit à recourir à une assistance prolongée proposée par le fournisseur ou par le fournisseur de services cloud afin de continuer à bénéficier des correctifs pendant que vous planifiez la migration.
•   Les mises à niveau majeures de PostgreSQL nécessitent un temps de test conséquent : les problèmes de compatibilité liés aux extensions et aux pilotes entraînent généralement plus de travail que la migration elle-même.

Votre instance PostgreSQL 12 n'a pas planté le 15 novembre 2024. Elle n'a probablement même pas connu le moindre accroc. Et c'est là que réside le piège.

PostgreSQL 12 a atteint sa fin de vie le 14 novembre 2024. La communauté a publié une dernière version hors cycle, la 12.22, une semaine plus tard pour corriger une régression – puis a définitivement fermé la branche. Le logiciel fonctionne toujours. Mais les correctifs de sécurité et les corrections de bogues, eux, ne sont plus assurés. La plupart des équipes le laissent discrètement en production et se consacrent à des tâches plus urgentes. Puis, quelques mois plus tard, une vulnérabilité récemment révélée s’avère affecter la gamme 12.x, aucun correctif communautaire n’est prévu, et un système qui « fonctionnait très bien » présente soudainement une faille connue et irréparable.

Ce guide explique ce qui a réellement changé à la date de fin de vie, à quoi ressemblent concrètement les risques réels et quelles sont vos options pour rétablir un état de sécurité à jour – avec des remarques franches sur les difficultés que présente chaque voie.

Que signifie la fin de vie de PostgreSQL 12 ?

La fin de vie signifie que le PostgreSQL Global Development Group a publié la dernière version 12.x et clôturé la branche. Plus aucun correctif de sécurité. Plus aucune correction de bogue. Si une vulnérabilité récemment révélée affecte PostgreSQL 12, elle restera sans correctif du côté de la communauté, de manière définitive. Une base de données en fin de vie traitant des données réglementées ou prenant en charge une application exposée à Internet devient un risque croissant chaque fois qu’une nouvelle faille apparaît sur sa branche, car aucun correctif communautaire ne sera publié.

Dates importantes de fin de vie (EOL) de PostgreSQL à retenir

Le projet PostgreSQL assure le support de chaque version majeure pendant cinq ans à compter de sa sortie initiale, puis publie une dernière version mineure avant de mettre fin au support. Il n'y a pas de distinction entre les niveaux « actif » et « de maintenance » comme pour Node.js LTS. Il s'agit d'une période unique de cinq ans, après quoi la branche est retirée.

Version	Publié	Fin de vie	Statut
18	septembre 2025	novembre 2030	Pris en charge (dernière version)
17	septembre 2024	novembre 2029	Prise en charge
16	septembre 2023	novembre 2028	Prise en charge
15	Octobre 2022	novembre 2027	Prise en charge
14	septembre 2021	novembre 2026	Prise en charge (bientôt terminée)
13	septembre 2020	novembre 2025	EOL
12	Octobre 2019	novembre 2024	EOL
11	Octobre 2018	Novembre 2023	EOL

Si vous êtes sur la version 12, vous êtes à deux versions majeures en dessous de la branche la plus ancienne prise en charge. Si vous êtes sur la version 13, vous avez rejoint le club des versions en fin de vie en novembre 2025. La version 14 semble sûre sur le papier, mais sa fin de vie est prévue pour le 12 novembre 2026 – plus proche que la plupart des gens ne le pensent.

Pourquoi certaines versions de PostgreSQL sont-elles retirées ?

Le fait de mettre fin à une version majeure ne signifie pas que la communauté fait des difficultés. Il s'agit d'un compromis délibéré qui permet d'assurer la bonne santé du projet. Plusieurs facteurs expliquent cette décision.

Le délai de cinq ans est fixé par la conception même du système

PostgreSQL s'engage à assurer un support de cinq ans pour chaque version majeure, à compter de la date de sortie initiale. Cette prévisibilité est vraiment utile : vous pouvez consulter n'importe quelle version et connaître sa date d'expiration plusieurs années à l'avance.

Le problème, c’est que le temps ne tient pas compte de votre retard dans la migration. PostgreSQL 12 a été lancé en octobre 2019 ; sa fin de vie (EOL), prévue pour novembre 2024, était donc en réalité fixée dès le premier jour. Les équipes qui considéraient cette date comme un « jour lointain » ont vu celle-ci arriver dans les délais, comme c’est souvent le cas.

L'entretien des anciennes succursales revient cher

Chaque version majeure prise en charge correspond à une branche distincte que les responsables doivent mettre à jour, tester et publier. Le portage d'un simple correctif de sécurité sur cinq ou six branches actives représente un véritable travail d'ingénierie, assuré par les contributeurs du projet et les entreprises qui les soutiennent.

À un certain moment, le coût lié au maintien d’une ancienne branche dépasse les avantages qu’elle apporte. Les chemins de code divergent. L’infrastructure de test vieillit. Une correction qui s’effectue facilement sur la branche actuelle peut nécessiter une intervention complexe sur une base de code vieille de cinq ans. La suppression de la branche la plus ancienne permet au projet de consacrer cette énergie aux versions que la plupart des utilisateurs exploitent réellement.

Les correctifs de sécurité rétroactifs ont une durée de validité limitée

Certaines vulnérabilités sont faciles à corriger dans un code ancien. D'autres dépendent d'une architecture qui a évolué dans les versions plus récentes, et le portage de ces correctifs vers une branche bien plus ancienne peut s'avérer non seulement fastidieux, mais aussi véritablement risqué. Le portage lui-même pourrait introduire des régressions dans des chemins de code que personne n'a utilisés depuis des années.

Une fois qu'une version est en fin de vie (EOL), la charge liée au portage retombe sur vous, ou sur la personne à qui vous confiez cette tâche.

Risques liés à l'utilisation d'une version de PostgreSQL en fin de vie (EOL)

Les risques liés au maintien de PostgreSQL 12 ne sont pas hypothétiques. Ils s'aggravent à mesure que l'on attend.

Vulnérabilités de sécurité non corrigées

Toute vulnérabilité signalée concernant PostgreSQL 12 après la fin de son cycle de vie (EOL) restera non corrigée par la communauté, un point c'est tout. La version hors cycle 12.22, publiée le 21 novembre 2024, a été la dernière version corrective que la version 12 recevra jamais – elle a été publiée pour corriger une régression présente dans la version 12.21, et non pour prolonger le support. Toute vulnérabilité révélée après cette date n’affectera pas la version 12, ou bien, si elle l’affecte, ne fera jamais l’objet d’un correctif de la part de la communauté.

La tendance générale ne fait qu'aggraver la situation. Les outils de suivi des vulnérabilités ont recensé 16 CVE concernant PostgreSQL au cours du premier semestre 2026 – soit déjà plus que sur l’ensemble de l’année 2025 – avec un score de gravité moyen supérieur à 7. La mise à jour de sécurité de mai 2026 a à elle seule corrigé 11 vulnérabilités sur l’ensemble des branches prises en charge, avec des scores de gravité atteignant 8,8. Toutes ces vulnérabilités ne concernent pas la version 12. La préoccupation porte sur ce qui se passera lorsqu’un problème nouvellement révélé concernera cette version : la communauté ne produira plus de correctif pour y remédier.

Pour plus d'informations sur la protection de votre environnement contre les risques liés à l'absence de correctifs, vous pouvez consulter notre guide détaillé sur les bonnes pratiques de sécurité pour PostgreSQL. Vous pouvez également découvrir les vulnérabilités de PostgreSQL et les risques de sécurité qu'elles peuvent entraîner dans notre guide approfondi.

C'est précisément cette lacune que le support étendu proposé par les éditeurs vise à combler. Vous trouverez plus d'informations à ce sujet dans la section « Options » ci-dessous.

Défauts de conformité et d'audit

PCI DSS exige explicitement de corriger les vulnérabilités connues et d'assurer le suivi des technologies en fin de vie relevant du champ d'application. La norme HIPAA et SOC 2 ne mentionnent pas ouvertement les logiciels en fin de vie, mais les auditeurs considèrent une base de données qui ne peut plus recevoir de correctifs de sécurité comme un risque imminent. Dans tous les cas, l’argument « le fournisseur a cessé de fournir des correctifs » est difficile à défendre, quel que soit le niveau de sécurisation du reste de votre infrastructure.

Les auditeurs vérifient directement l'état de prise en charge des versions, à l'aide de questionnaires, d'analyses de vulnérabilité et d'inventaires des actifs. « Nous travaillons à la mise à niveau » n'est pas une réponse convaincante lorsque la date de fin de vie (EOL) a été dépassée en novembre 2024. Les constatations ont des conséquences financières réelles : contrats perdus, délais de mise en conformité et, dans les secteurs réglementés, amendes.

Dérive de l'écosystème

La sécurité retient l'attention, mais le problème plus insidieux réside dans le fait que tout ce qui gravite autour de la base de données s'éloigne progressivement de la version 12. Les responsables de la maintenance des extensions cessent de la tester. Les pilotes clients ne la prennent plus en charge. Les fournisseurs de services gérés facturent des suppléments pour une prise en charge prolongée, bloquent les nouveaux déploiements ou programment des mises à niveau obligatoires.

Aucun de ces éléments n'est catastrophique en soi, mais ils s'accumulent. À terme, un responsable de bibliothèque publie une version qui repose sur le comportement de PostgreSQL 14 ou plus, ou bien votre solution d'intégration de surveillance cesse de prendre en charge la version 12.x. Vous vous retrouvez alors avec une base de données que vous ne pouvez pas modifier en toute sécurité et dont vous ne pouvez pas vous détacher facilement.

Options après la fin de vie de PostgreSQL 12

Quatre options réalistes s'offrent à vous. Le choix de la bonne option dépend de votre tolérance au risque : êtes-vous en mesure de faire face aux perturbations qu'entraînerait une mise à niveau dès maintenant, ou préférez-vous continuer à appliquer les correctifs et à respecter la conformité tout en élaborant une stratégie de migration stable ?

1. Assistance étendue assurée par le fournisseur

Si vous ne pouvez pas effectuer la migration immédiatement, mais que vous ne pouvez pas non plus continuer à utiliser un logiciel non mis à jour, le support prolongé constitue la solution intermédiaire. Quelques fournisseurs proposent cette option. Le service « Endless Lifecycle Support » de TuxCare couvre actuellement PostgreSQL 13, et la société a annoncé son intention d’y ajouter la version 14 avant sa date de fin de vie.

L'intérêt d'une extension de la prise en charge n'est pas d'éviter indéfiniment toute mise à niveau. Il s'agit plutôt de transformer une échéance stricte en un projet planifié. Au lieu d'une migration d'urgence casée à la va-vite dans un sprint entre deux développements de fonctionnalités, vous disposez d'une instance corrigée et d'une marge de manœuvre suffisante pour effectuer la migration lorsque vous serez prêt, plutôt que lorsque la publication d'une vulnérabilité CVE ou un auditeur vous y contraindra.

Cette option convient aux équipes évoluant dans des environnements réglementés, à celles qui utilisent des configurations fortement personnalisées, ou à toute personne dont la fenêtre de migration réelle s'étend sur plusieurs mois. Elle vous fournit également un plan de mise à jour documenté à présenter aux auditeurs pendant que la mise à niveau proprement dite est encore en cours.

2. Passer à PostgreSQL 18

PostgreSQL 18 est la version actuelle, dont le support est assuré jusqu’en novembre 2030. En adoptant directement cette version, vous bénéficierez d’un délai maximal avant de devoir répéter cet exercice, ainsi que des dernières améliorations en matière de performances et de fonctionnalités.

Le compromis réside dans la durée : passer de la version 12 à la version 18 implique six sauts de version majeure, ce qui signifie davantage de changements de comportement à vérifier d’un seul coup : différences entre les planificateurs, paramètres obsolètes et compatibilité des extensions à tous les niveaux. Utilisez pg_upgrade (en installant les binaires de la nouvelle version parallèlement à ceux de l’ancienne) plutôt qu’une sauvegarde et une restauration complètes, mais prévoyez une période de test suffisamment longue :

pg_upgrade \

  –old-datadir /var/lib/postgresql/12/main \

  –new-datadir /var/lib/postgresql/18/main \

  –old-bindir /usr/lib/postgresql/12/bin \

  –new-bindir /usr/lib/postgresql/18/bin \

  –vérifier

Les chemins indiqués correspondent aux valeurs par défaut de Debian/Ubuntu – adaptez-les à votre distribution. Exécutez la commande avec –check : cela permet de détecter de nombreux problèmes bloquants avant que vous ne vous engagiez, même si cela ne détectera pas tous les problèmes liés aux applications ou aux performances.

3. Passer à PostgreSQL 17, 16 ou 15 (toujours pris en charge)

Si le passage à la version 18 vous semble trop radical, PostgreSQL 17 (fin de vie en novembre 2029), 16 (fin de vie en novembre 2028) et 15 (fin de vie en novembre 2027) bénéficient toujours du soutien de la communauté et se rapprochent davantage du comportement de la version 12. De nombreuses équipes choisissent l’une de ces versions comme étape intermédiaire délibérée : une durée de support suffisante pour être pertinente, et moins de surprises que la dernière version.

Gardez toutefois le calendrier à l'esprit. Opter pour la version 15 en 2026 ne vous laisse qu'à peine un an et demi avant de devoir recommencer à planifier la fin de vie du produit ; les versions 17 ou 16 offrent quant à elles une véritable marge de manœuvre à la stratégie intermédiaire. Il est judicieux de privilégier l'une de ces versions plutôt que la 18 lorsque vos extensions n'ont pas encore été certifiées pour la version la plus récente, ou lorsque vous préférez une version ayant fait ses preuves depuis plus longtemps en production.

Conseil de pro : Exécutez SELECT * FROM pg_extension; sur votre instance 12.x en production avant de choisir une version cible, puis vérifiez chaque extension par rapport à la version candidate. Ce sont généralement les extensions, et non le cœur de PostgreSQL, qui bloquent les mises à niveau en cours de projet.

4. Assistance étendue pour le cloud géré

Si vous utilisez Amazon RDS, Google Cloud SQL ou un déploiement éligible d’Azure Database for PostgreSQL, votre fournisseur peut proposer une assistance étendue payante pour certaines versions en fin de vie (EOL) ; les règles de disponibilité et d’inscription varient selon le service et la version. Amazon RDS a intégré PostgreSQL 12 à son programme de support étendu RDS après la fin de sa période de support standard, le 28 février 2025, avec des surcoûts par vCPU. Google Cloud SQL a commencé à facturer des frais de support étendu pour les versions majeures en fin de vie (EOL) à compter du 1er mai 2025. Azure inscrit désormais automatiquement les serveurs fonctionnant sur des versions non prises en charge au programme de support étendu automatiquement, la facturation pour la version 13 débutant le 1er août 2026.

Cela vous permet de bénéficier de mises à jour de sécurité gérées par le fournisseur sans avoir à gérer vos propres backports PostgreSQL, ce qui est vraiment utile. Les surcoûts augmentent toutefois avec le temps – le tarif d’AWS s’alourdit après les deux premières années – ; considérez donc cette solution comme une période de grâce limitée, et non comme une stratégie à long terme. Lisez attentivement la tarification par instance avant de conclure qu’il s’agit de l’option la moins chère.

Voici un aperçu de la décision :

Si votre situation est…	Le meilleur coup
Je ne peux pas migrer tout de suite, je dois donc rester à jour et conforme	Assistance prolongée assurée par le fournisseur (par exemple, l’offre « Endless Lifecycle Support » de TuxCare)
Prêt à migrer, vous souhaitez bénéficier d'une période de support aussi longue que possible	Passer à PostgreSQL 18
Prêt à migrer, vous souhaitez éviter les mauvaises surprises ?	Passer à la version 17 ou 16
Dans le cloud géré, s'accorder un répit à court terme	Assistance étendue du fournisseur

Planifier la migration avant que cela ne devienne urgent

Les équipes qui gèrent efficacement la fin de vie d'un produit la traitent comme n'importe quel autre projet planifié. Celles qui rencontrent des difficultés ont tendance à considérer la date de fin de vie comme le moment où il faut commencer à y réfléchir, ce qui est environ un an trop tard.

Un plan de migration viable comprend généralement :

•   Inventaire. Toutes les instances 12.x, y compris la réplique oubliée et le serveur d'analyse dont personne n'est responsable.
•   Audit des dépendances. Extensions, pilotes clients, ORM et outils de réplication : chacun est vérifié par rapport à votre version cible.
•   Une décision concernant la version cible. Choix fondé sur la compatibilité des extensions et la durée de prise en charge, et non sur une intuition.
•   Une procédure de mise à niveau éprouvée. pg_upgrade, ou la réplication logique pour un temps d'indisponibilité quasi nul, testée en environnement de préproduction avant d'intervenir sur l'environnement de production.
•   Une solution de transition. Comment garantir votre sécurité d'ici au jour de la migration. Cela passe souvent par une extension de support de la part du fournisseur ou du cloud ; les contrôles compensatoires documentés constituent une alternative moins sûre.
•   Un plan de restauration. Parce qu’il y aura forcément un imprévu, et que vous voulez une solution de secours qui ne se résume pas à « restaurer à partir de la sauvegarde d’hier soir ».

Retour à la réalité : Les fournisseurs adorent qualifier les mises à niveau majeures de « sans heurts ». Ce n’est pas le cas. Même une exécution sans accroc de pg_upgrade vous oblige à revalider les extensions, à réajuster les configurations et à surveiller l’évolution des plans de requêtes. Pour un environnement de production présentant des dépendances importantes, prévoyez plusieurs semaines de tests, et pas seulement une fenêtre de maintenance.

Que faire si PostgreSQL 12 est toujours en production ?

PostgreSQL 12 ne va pas cesser de fonctionner, et c’est précisément pour cette raison qu’il est facile de le négliger jusqu’à ce qu’une vulnérabilité CVE ou un audit rende la situation urgente. En résumé : prenez une décision en toute connaissance de cause. Passez à une version prise en charge si vous pouvez effectuer la migration. Si ce n’est pas possible, assurez-vous de disposer d’une couverture de correctifs afin que le « pas encore » ne se transforme pas en « exposé pendant un an ».

En ce qui concerne le support prolongé, TuxCare prend actuellement en charge la version 13 si vous avez besoin d’une solution commerciale de correctifs pendant que vous planifiez la mise à niveau ; la prise en charge de la version 14 a été annoncée avant sa fin de vie. Vérifiez les versions prises en charge auprès de chaque fournisseur avant de considérer le support étendu comme une solution de transition.

Commencez par dresser un état des lieux de votre environnement 12.x : combien d'instances, quelles extensions, quels éléments en dépendent. Cet inventaire suffit généralement à déterminer clairement la voie à suivre. Le pire scénario est celui où vous ne faites aucun choix.

FAQ