[{"data":1,"prerenderedAt":157},["ShallowReactive",2],{"seo-verification":3,"blog-postgresql-fin-de-vie-planifier-montee-version-en":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 end of life: plan your major upgrade","PostgreSQL supports each major version for five years, ending in November. Find out which one you run and plan the upgrade without losing data.",7,0,false,"2026-08-05T00:00:00+00:00",{"id":16,"name":17,"slug":18,"color":19,"icon":20},6,"Databases","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 ships one major version per year and patches each one for five years. Once that window closes, the database keeps running exactly as it did the day before, simply without fixes: on a VPS, nothing warns you. This guide explains how to read your version, what the end of support actually changes, and how to plan the upgrade without losing data.",[28,32,41,44,66,106],{"type":29,"title":30,"body":31},"h2","One major version per year, five years of fixes","PostgreSQL ships a major version roughly once a year and maintains it for five years. After that, a final minor release comes out and the branch reaches end of life, always on the November minor release: PostgreSQL 13 stopped on 13 November 2025, and PostgreSQL 14 will stop on 12 November 2026. The branches still followed run from 14 to 18; 18 has been available since 25 September 2025, and 19 is announced for September 2026.",{"type":33,"title":34,"items":35},"ul","What the end of support actually changes",[36,37,38,39,40],"**No more fixes** — a vulnerability published after end of life will not be patched on your branch: the code stays as it is, indefinitely.","**Extensions fall behind** — `PostGIS`, `pgvector` or `TimescaleDB` stop publishing packages for a dead branch, and the next requirement becomes a blocker.","**Distribution packages disappear** — no more updates through `apt`, and reinstalling the VPS will not necessarily bring back the same version.","**Compliance notices it** — an audit, a customer questionnaire or an insurance contract will flag an unmaintained component long before an incident happens.","**Clients and drivers move on** — recent tooling (`psql`, `pg_dump`, application drivers) assumes supported server versions; the gap eventually produces errors that are hard to read.",{"type":29,"title":42,"body":43},"Finding out which version you actually run","The server is authoritative, not your deployment file. Connect and run `SELECT version();`, or `SHOW server_version;` for the bare value. On Debian and Ubuntu, `pg_lsclusters` lists every cluster with its version, its port and its state, including the ones forgotten during an earlier upgrade. In containers, the image tag is misleading: replacing `postgres:16` with a newer tag does not convert the files already written in the volume.",{"type":45,"title":46,"steps":47},"steps","Planning the major upgrade",[48,51,54,57,60,63],{"title":49,"body":50},"Back up, then verify the backup","Export roles and global settings with `pg_dumpall --globals-only`, then each database with `pg_dump -Fc`. A backup only counts once it has been restored: replay it into a throwaway cluster and compare row counts on your main tables.",{"title":52,"body":53},"Choose between logical export and in-place conversion","`pg_dump` followed by `pg_restore` rebuilds everything in a fresh cluster: simple, reversible, but the downtime follows the volume. `pg_upgrade` converts the catalog of the existing cluster in minutes, provided you install the binaries of both versions side by side.",{"title":55,"body":56},"Rehearse the migration on a copy","Do not test on the machine serving traffic. Spin up a second VPS, restore the backup there, then run `pg_upgrade --check`: it validates compatibility without writing anything and lists the manual adjustments to expect. Time the operation: that measurement sets your window.",{"title":58,"body":59},"Cut over with writes stopped","Stop the application, then shut the server down cleanly. Run the conversion or the restore, restart on the new cluster, and let traffic back in after a first check. Choose the mode knowingly: `--link` and `--swap` speed up the cutover but leave the old cluster unusable.",{"title":61,"body":62},"Check after the cutover","Confirm the version with `SELECT version();`, update your extensions with `ALTER EXTENSION ... UPDATE`, then regenerate optimizer statistics with `vacuumdb --all --analyze-in-stages`. Only delete the old data directory after several days of real production use, using the script `pg_upgrade` points to.",{"title":64,"body":65},"Run a full backup cycle again","Your archives from before the cutover describe a cluster that no longer exists. Take a full backup on the new version and test its restore: our guide on encrypted backups with restic covers rotation and integrity checking. On a Cloud VPS, that schedule stays yours.",{"type":67,"title":68,"headers":69,"rows":73},"comparison","pg_dump\u002Frestore or pg_upgrade: how to decide",[70,71,72],"Criterion","pg_dump \u002F pg_restore","pg_upgrade",[74,78,82,86,90,94,98,102],[75,76,77],"Principle","Logical export, then reimport into a fresh cluster","Conversion of the existing cluster's catalog",[79,80,81],"Downtime","Proportional to the data volume","A few minutes, largely volume-independent in `--link` or `--swap` mode",[83,84,85],"Disk space","Room for the archive, then for both clusters","`--link` does not copy the files, but requires the same file system",[87,88,89],"Rollback","The old cluster stays intact and the archive stays replayable","After `--link` or `--swap`, the old cluster can no longer be started",[91,92,93],"Pre-flight check","Failure shows up late, during the import","`pg_upgrade --check` validates before any write",[95,96,97],"Optimizer statistics","Fully rebuilt after the import","Mostly carried over since PostgreSQL 18, rebuilt before that",[99,100,101],"Parallelism","`pg_dump -j` and `pg_restore -j`","`--jobs` to process several databases in parallel",[103,104,105],"Typical use case","Modest volumes, a change of machine, a reorganization","Large volumes, in-place upgrades, a short window",{"type":107,"title":108,"body":109},"tip","The real check is the restore","A branch at end of life raises no alert, and neither does a backup that has never been restored. Before the cutover, list the archive with `pg_restore --list`, restore it fully on a separate machine, and compare row counts on your sensitive tables. Then write your branch's end-of-life date into the calendar that already holds your renewals: a silent deadline becomes a planned task.","An up-to-date database on a VPS you control","On a ServOrbit Cloud VPS, you choose the major PostgreSQL version, you upgrade when your window allows it and you keep the old cluster while you validate. Full root access, no version imposed on you.","Choose my Cloud VPS","\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 on a VPS: a reliable and controlled database","Host PostgreSQL on a VPS: volumes, backups, restricted network access and sound configuration for your 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 in 2026: Comparison and Migration Guide","Redis returned to an OSI-compatible license (AGPLv3) in May 2025, but Valkey 9.1 is now the default cache package on Ubuntu, Debian and Fedora, delivering +8% ops\u002Fsec and -22% P99 latency. Here's how to choose and migrate in 4 steps.","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","Automate Your VPS Backups with Restic","Automate your VPS backups with Restic: encrypted snapshots, deduplication and shipping to S3 or any object backend.",781,"2026-02-27T00:00:00+00:00",{"id":120,"name":147,"slug":148,"color":149,"icon":150},"Security & 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",1785896850662]