[{"data":1,"prerenderedAt":157},["ShallowReactive",2],{"seo-verification":3,"blog-postgresql-fin-de-vie-planifier-montee-version-fr":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"id":7,"slug":8,"title":9,"excerpt":10,"readTime":11,"views":12,"isPinned":13,"publishedAt":14,"category":15,"categories":21,"featuredImage":23,"bgImage":24,"posterImage":25,"relatedSolution":23,"intro":26,"sections":27,"ctaTitle":110,"ctaBody":111,"ctaButton":112,"ctaUrl":113,"relatedPosts":114},225,"postgresql-fin-de-vie-planifier-montee-version","PostgreSQL en fin de vie : planifier la montée de version","PostgreSQL suit chaque version majeure cinq ans, jusqu'à un arrêt en novembre. Repérez la vôtre et planifiez la montée sans perdre de données.",7,0,false,"2026-08-05T00:00:00+00:00",{"id":16,"name":17,"slug":18,"color":19,"icon":20},6,"Bases de données","bases-de-donnees","bg-teal-500\u002F10 text-teal-400","database",[22],{"id":16,"name":17,"slug":18,"color":19,"icon":20},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fpostgresql-fin-de-vie-planifier-montee-version-poster.svg","PostgreSQL publie une version majeure par an et corrige chacune pendant cinq ans. Passé ce délai, la base continue de tourner exactement comme la veille, simplement sans correctif : sur un VPS, aucun message ne vous prévient. Ce guide explique comment lire votre version, ce que la fin de support change réellement, et comment planifier la montée sans perdre de données.",[28,32,41,44,66,106],{"type":29,"title":30,"body":31},"h2","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.",{"type":33,"title":34,"items":35},"ul","Ce que la fin de support change réellement",[36,37,38,39,40],"**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`, `pgvector` ou `TimescaleDB` cessent 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.",{"type":29,"title":42,"body":43},"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.",{"type":45,"title":46,"steps":47},"steps","Planifier la montée de version",[48,51,54,57,60,63],{"title":49,"body":50},"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.",{"title":52,"body":53},"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.",{"title":55,"body":56},"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.",{"title":58,"body":59},"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.",{"title":61,"body":62},"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`.",{"title":64,"body":65},"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.",{"type":67,"title":68,"headers":69,"rows":73},"comparison","pg_dump\u002Frestore ou pg_upgrade : comment trancher",[70,71,72],"Critère","pg_dump \u002F pg_restore","pg_upgrade",[74,78,82,86,90,94,98,102],[75,76,77],"Principe","Export logique, puis réimport dans un cluster neuf","Conversion du catalogue du cluster existant",[79,80,81],"Temps d'arrêt","Proportionnel au volume de données","Quelques minutes, peu sensible au volume en mode `--link` ou `--swap`",[83,84,85],"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",[87,88,89],"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",[91,92,93],"Contrôle préalable","L'échec se découvre tard, pendant l'import","`pg_upgrade --check` valide avant toute écriture",[95,96,97],"Statistiques de l'optimiseur","Entièrement à reconstruire après l'import","Transférées en grande partie depuis PostgreSQL 18, à reconstruire avant",[99,100,101],"Parallélisme","`pg_dump -j` et `pg_restore -j`","`--jobs` pour traiter plusieurs bases en parallèle",[103,104,105],"Terrain de prédilection","Volumes modestes, changement de machine, réorganisation","Gros volumes, montée sur place, fenêtre courte",{"type":107,"title":108,"body":109},"tip","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.","Une base à jour sur un VPS que vous maîtrisez","Sur un VPS Cloud ServOrbit, vous choisissez la version majeure de PostgreSQL, vous montez quand votre fenêtre le permet et vous gardez l'ancien cluster le temps de valider. Accès root complet, aucune version imposée.","Choisir mon VPS Cloud","\u002Fvps-cloud",[115,129,139],{"id":116,"slug":117,"title":118,"excerpt":119,"readTime":120,"views":121,"isPinned":13,"publishedAt":122,"category":123,"categories":124,"featuredImage":23,"bgImage":24,"posterImage":126,"relatedSolution":127},56,"heberger-postgresql-vps","PostgreSQL sur VPS : base fiable et contrôlée","Hébergez PostgreSQL sur VPS : volumes, sauvegardes, accès réseau limité et configuration saine pour vos applications.",8,2240,"2026-04-25T00:00:00+00:00",{"id":16,"name":17,"slug":18,"color":19,"icon":20},[125],{"id":16,"name":17,"slug":18,"color":19,"icon":20},"\u002Fblog\u002Fcovers\u002Fheberger-postgresql-vps-poster.svg",{"categorySlug":18,"appSlug":128},"postgresql",{"id":130,"slug":131,"title":132,"excerpt":133,"readTime":11,"views":12,"isPinned":13,"publishedAt":134,"category":135,"categories":136,"featuredImage":23,"bgImage":24,"posterImage":138,"relatedSolution":23},217,"valkey-vs-redis-migration-2026","Valkey vs Redis en 2026 : comparatif et guide de migration","Redis est revenu en AGPLv3 en mai 2025, mais Valkey 9.1 s'impose comme paquet par défaut sur Ubuntu, Debian et Fedora avec +8 % d'ops\u002Fsec et -22 % de latence P99. Voici comment choisir et migrer en 4 étapes.","2026-08-03T00:00:00+00:00",{"id":16,"name":17,"slug":18,"color":19,"icon":20},[137],{"id":16,"name":17,"slug":18,"color":19,"icon":20},"\u002Fblog\u002Fcovers\u002Fvalkey-vs-redis-migration-2026-poster.svg",{"id":140,"slug":141,"title":142,"excerpt":143,"readTime":11,"views":144,"isPinned":13,"publishedAt":145,"category":146,"categories":151,"featuredImage":23,"bgImage":24,"posterImage":153,"relatedSolution":154},113,"sauvegardes-restic-vps","Automatiser les sauvegardes de votre VPS avec Restic","Automatisez les sauvegardes de votre VPS avec Restic : snapshots chiffrés, déduplication et envoi vers S3 ou tout backend objet.",781,"2026-02-27T00:00:00+00:00",{"id":120,"name":147,"slug":148,"color":149,"icon":150},"Sécurité & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[152],{"id":120,"name":147,"slug":148,"color":149,"icon":150},"\u002Fblog\u002Fcovers\u002Fsauvegardes-restic-vps-poster.svg",{"categorySlug":155,"appSlug":156},"securite","restic",1785896850551]