Plus que deux mois avant la fin de prise en charge de PostgreSQL 14 : s'entraîner à la restauration avant la mise à niveau
Certaines équipes ont planifié la montée de version de leur base de données sans connaître le temps nécessaire pour revenir en arrière en cas d'échec. Si vous utilisez PostgreSQL 14, le livrable dont vous avez besoin maintenant n'est pas simplement le nom d'une nouvelle version, mais un plan de migration permettant une restauration. Au 14 septembre 2026, il reste environ deux mois avant la date officielle de fin de prise en charge.
Fait avéré : le support communautaire et les contrats d'hébergement diffèrent
La politique officielle de gestion des versions de PostgreSQL assure le support d'une version majeure pendant cinq ans et annonce la dernière version corrective de PostgreSQL 14 pour le 12 novembre 2026. Il s'agit du calendrier du support communautaire. Les fenêtres de mise à niveau des services gérés, le support étendu éventuel et la tarification doivent être vérifiés séparément dans la documentation et le contrat de votre fournisseur.
Il convient également de distinguer les mises à jour mineures au sein d'une même version majeure des montées de version majeure. L'application des derniers correctifs pour PostgreSQL 14 ne remplace pas le passage à la version 15 ou supérieure. À l'inverse, il n'est pas judicieux de reporter indéfiniment les correctifs nécessaires sur la version actuelle sous prétexte qu'un plan de migration majeure existe.
Premier livrable : la liste des dépendances plutôt que la taille des données
À partir d'ici, il s'agit de recommandations opérationnelles et non de la politique de support officielle elle-même. Commencez par consigner sur un document unique la version de la base de données par service, les modules d'extension et leurs versions, les pilotes de connexion, les traitements par lots (batchs), l'emplacement de stockage des sauvegardes et la configuration de réplication. Ne choisissez pas la version cible simplement parce qu'elle est la plus récente : vérifiez également l'environnement d'hébergement réel et la compatibilité des extensions.
Supposer qu'une base de données est petite et que la migration sera donc rapide est insuffisant. Si les extensions ou les requêtes utilisées sur des parcours critiques pour l'activité — comme la première consultation après connexion ou la mise à jour de l'état d'un paiement — changent, la migration peut échouer même si la copie des données est brève. Le but de cet inventaire est d'identifier les dépendances orphelines sans responsable désigné.
Deuxième livrable : un résultat de restauration plutôt qu'un message de succès de sauvegarde
Restaurez une sauvegarde récente dans un environnement isolé et exécutez les flux types de lecture et d'écriture de l'application. Lors de cet exercice, vérifiez impérativement la cible de connexion au préalable afin d'éviter d'envoyer des écritures vers la base de production. Les copies restaurées contenant des données réelles doivent être traitées dans le respect des contrôles d'accès existants.
Distinguer l'heure de début de sauvegarde, l'heure de fin de restauration et l'heure de fin de validation évite de confondre le temps de récupération des fichiers avec le moment où le service peut à nouveau écrire. Plutôt que de valider uniquement de petits échantillons artificiellement rapides, mesurez les durées sur des copies de taille proche de la production, tout en consignant les contraintes de coût et d'espace disque.
La réussite du contrôle pg_upgrade ne remplace pas la validation du service
La documentation officielle de pg_upgrade explique que l'option --check permet d'effectuer un contrôle de compatibilité avant la mise à niveau effective. La compatibilité des modules externes doit toutefois être examinée séparément, et les bibliothèques partagées adaptées au nouveau serveur sont indispensables. Ne considérez pas que le succès de la commande de vérification garantit la validité de toutes les requêtes applicatives et de leurs performances.
Le mode --link présente notamment la contrainte de rendre l'ancien cluster inutilisable en l'état une fois le nouveau démarré. Choisir ce mode uniquement pour sa rapidité peut vous priver du plan de retour arrière prévu. Effectuez des répétitions dans des conditions identiques à celles de la migration réelle, et précisez le moment où un retour arrière fondé sur une restauration devient nécessaire.
Les critères à définir avant la reprise des écritures
Définissez à l'avance les critères de réussite afin de ne pas avoir à improviser d'accord le jour de la bascule. Par exemple, vous pouvez associer un responsable à chaque critère : exécution complète des lectures et écritures sur les API critiques, reprise des batchs sans doublons, cohérence des agrégats métier sur les tables principales, ou encore vérification de l'état de la réplication. Il ne s'agit pas d'imposer des valeurs de référence identiques à tous les services, mais d'illustrer la démarche.
Si l'on commence à écrire sur la nouvelle base de données puis que l'on revient à la sauvegarde précédente, la préservation des modifications intervenues entre-temps pose problème. Rallumer simplement l'ancien serveur et effectuer un retour arrière sans perte de données sont deux démarches bien distinctes. Le niveau de perte de données et la durée d'interruption acceptables doivent être convenus par les responsables du service.
Actions de la semaine et objections fréquentes
S'il est difficile de migrer toutes les bases de données d'un coup, mesurez le temps de restauration, de validation et de retour arrière sur un service présentant le moins de dépendances, et utilisez ces résultats pour planifier les autres services. Rassembler dans un même document les responsables, les dates de bascule envisagées et les critères d'arrêt en cas d'échec de validation transforme un projet composé uniquement d'échéances en actions concrètes et exécutables.
L'argument selon lequel le développement produit est prioritaire dans l'immédiat est compréhensible. Cependant, rester sans méthode de restauration éprouvée jusqu'à la date limite réduit les fenêtres de test disponibles. Cet article ne vante pas les gains de performances d'une version spécifique et ne prétend pas représenter l'avis de l'ensemble de la communauté. Il s'agit d'une proposition opérationnelle axée sur la capacité à gérer un échec de transition, plutôt que sur la vitesse d'adoption des dernières fonctionnalités.