Une version majeure par an, cinq ans de correctifs
PostgreSQL publie une version majeure environ une fois par an et la maintient cinq ans. Passé ce délai, une dernière mineure paraît et la branche passe en fin de vie, toujours sur la livraison de novembre : PostgreSQL 13 s'est arrêté le 13 novembre 2025, PostgreSQL 14 s'arrêtera le 12 novembre 2026. Les branches encore suivies vont de 14 à 18 ; la 18 est disponible depuis le 25 septembre 2025, et la 19 est annoncée pour septembre 2026.
Ce que la fin de support change réellement
- Plus aucun correctif — une faille publiée après la fin de vie ne sera pas corrigée sur votre branche : le code reste tel quel, indéfiniment.
- Les extensions décrochent —
PostGIS,pgvectorouTimescaleDBcessent de publier des paquets pour une branche morte, et le prochain besoin devient bloquant. - Les paquets de la distribution disparaissent — plus de mise à jour par
apt, et une réinstallation du VPS ne retrouve pas forcément la même version. - La conformité s'en aperçoit — un audit, un questionnaire client ou un contrat d'assurance relèvent un composant non maintenu bien avant qu'un incident ne survienne.
- Les clients et les pilotes avancent — les outils récents (
psql,pg_dump, drivers applicatifs) supposent des versions serveur suivies ; l'écart finit par produire des erreurs difficiles à lire.
Savoir sur quelle version vous tournez
Le serveur fait autorité, pas votre fichier de déploiement. Connectez-vous et lancez SELECT version();, ou SHOW server_version; pour la valeur nue. Sur Debian et Ubuntu, pg_lsclusters liste chaque cluster avec sa version, son port et son état, y compris ceux oubliés lors d'une montée précédente. En conteneur, l'étiquette d'image induit en erreur : remplacer postgres:16 par une étiquette plus récente ne convertit pas les fichiers déjà écrits dans le volume.
Planifier la montée de version
Sauvegarder, puis vérifier la sauvegarde
Exportez les rôles et les paramètres globaux avec pg_dumpall --globals-only, puis chaque base avec pg_dump -Fc. Une sauvegarde ne compte que si elle a été restaurée : rejouez-la dans un cluster jetable et comparez les comptes de lignes de vos tables principales.
Choisir entre export logique et conversion en place
pg_dump suivi de pg_restore reconstruit tout dans un cluster neuf : simple, réversible, mais le temps d'arrêt suit le volume. pg_upgrade convertit le catalogue du cluster existant en quelques minutes, à condition d'installer les binaires des deux versions côte à côte.
Rejouer la migration sur une copie
Ne testez pas sur la machine qui sert le trafic. Montez un second VPS, restaurez-y la sauvegarde, puis exécutez pg_upgrade --check : il valide la compatibilité sans rien écrire et liste les ajustements manuels attendus. Chronométrez l'opération : cette mesure fixe votre fenêtre.
Basculer en coupant les écritures
Arrêtez l'application, puis le serveur proprement. Lancez la conversion ou la restauration, redémarrez sur le nouveau cluster, et remettez le trafic après un premier contrôle. Choisissez le mode en connaissance de cause : --link et --swap accélèrent la bascule mais rendent l'ancien cluster inutilisable.
Contrôler après la bascule
Confirmez la version avec SELECT version();, mettez à jour vos extensions avec ALTER EXTENSION ... UPDATE, puis régénérez les statistiques de l'optimiseur avec vacuumdb --all --analyze-in-stages. Ne supprimez l'ancien répertoire de données qu'après plusieurs jours d'exploitation réelle, avec le script indiqué par pg_upgrade.
Reprendre un cycle de sauvegarde complet
Vos archives d'avant la bascule décrivent un cluster qui n'existe plus. Reprenez une sauvegarde complète sur la nouvelle version et testez sa restauration : notre guide sur les sauvegardes chiffrées avec restic couvre la rotation et le contrôle d'intégrité. Sur un VPS Cloud, ce calendrier reste le vôtre.
pg_dump/restore ou pg_upgrade : comment trancher
| Critère | pg_dump / pg_restore | pg_upgrade |
|---|---|---|
| Principe | Export logique, puis réimport dans un cluster neuf | Conversion du catalogue du cluster existant |
| Temps d'arrêt | Proportionnel au volume de données | Quelques minutes, peu sensible au volume en mode `--link` ou `--swap` |
| Espace disque | De la place pour l'archive, puis pour les deux clusters | `--link` ne recopie pas les fichiers, mais impose le même système de fichiers |
| Retour arrière | L'ancien cluster reste intact et l'archive reste rejouable | Après `--link` ou `--swap`, l'ancien cluster n'est plus démarrable |
| Contrôle préalable | L'échec se découvre tard, pendant l'import | `pg_upgrade --check` valide avant toute écriture |
| Statistiques de l'optimiseur | Entièrement à reconstruire après l'import | Transférées en grande partie depuis PostgreSQL 18, à reconstruire avant |
| Parallélisme | `pg_dump -j` et `pg_restore -j` | `--jobs` pour traiter plusieurs bases en parallèle |
| Terrain de prédilection | Volumes modestes, changement de machine, réorganisation | Gros volumes, montée sur place, fenêtre courte |
Le vrai contrôle, c'est la restauration
Une branche en fin de vie n'émet aucune alerte, et une sauvegarde jamais restaurée non plus. Avant la bascule, listez l'archive avec pg_restore --list, restaurez-la entièrement sur une machine séparée, et comparez les comptes de lignes de vos tables sensibles. Notez ensuite la date de fin de vie de votre branche dans l'agenda qui porte vos renouvellements : une échéance silencieuse devient une tâche planifiée.
