{"id":2935,"date":"2026-11-02T10:40:36","date_gmt":"2026-11-02T10:40:36","guid":{"rendered":"https:\/\/hostry.com\/blog\/?p=2935"},"modified":"2026-11-02T10:40:38","modified_gmt":"2026-11-02T10:40:38","slug":"postgresql-14-end-of-life-upgrade","status":"publish","type":"post","link":"https:\/\/hostry.com\/blog\/postgresql-14-end-of-life-upgrade\/","title":{"rendered":"PostgreSQL 14 End of Life on November 12: Upgrade to 18 on a VPS"},"content":{"rendered":"\n
\"PostgreSQL<\/figure>\n\n\n\n
As of November 2, 2026, PostgreSQL 14 has 10 days of upstream support left, with its final minor release due on November 12. After that release, the PostgreSQL project publishes no more fixes for version 14, security fixes included, so the database should be on PostgreSQL 18 before the next round of advisories lands.<\/strong><\/em><\/pre>\n\n\n\n
Nothing shuts down on November 13. PostgreSQL 14 end of life<\/strong> means the installed binaries keep serving queries, and every bug or vulnerability found afterwards stays unpatched on your machine. On an unmanaged Hostry KVM VPS<\/a><\/strong> you run the major upgrade yourself, and on Ubuntu or Debian the tools for it ship with the PostgreSQL packages. The steps assume one server with one 14 cluster.<\/p>\n\n\n\n
PostgreSQL 14 end of life: what stops on November 12<\/h2>\n\n\n\n
The PostgreSQL versioning policy<\/a><\/strong> gives each major five years, so the PostgreSQL 14 EOL date is November 12, 2026. A server still on an older 14.x minor than 14.24 also lacks security fixes that have already been published.<\/p>\n\n\n\n
Major version<\/th>Latest minor (November 2, 2026)<\/th>Final release<\/th><\/tr><\/thead>
18<\/td>18.6<\/td>November 14, 2030<\/td><\/tr>
17<\/td>17.11<\/td>November 8, 2029<\/td><\/tr>
16<\/td>16.15<\/td>November 9, 2028<\/td><\/tr>
15<\/td>15.19<\/td>November 11, 2027<\/td><\/tr>
14<\/td>14.24<\/td>November 12, 2026<\/td><\/tr>
13<\/td>13.23<\/td>Ended November 13, 2025<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Those are the PostgreSQL supported versions as the project lists them. Ubuntu 22.04 also carries 14 in its own archive (build 14.24-0ubuntu0.22.04.1<\/span>); unless your distribution has committed to patching it after PostgreSQL 14 end of life, plan as if it will not.<\/p>\n\n\n\n
Inventory the PostgreSQL 14 cluster first<\/h2>\n\n\n\n
The output of a few commands decides which method is possible. Start with the cluster list, the exact version and whether data checksums are on:<\/p>\n\n\n\n
pg_lsclusters\nsudo -u postgres psql -Atc \"SELECT version();\"\nsudo -u postgres psql -Atc \"SHOW data_checksums;\"<\/code><\/pre>\n\n\n\n
A 14 cluster answers off<\/span> to the last query unless someone enabled checksums at initdb<\/span> time, since they were opt-in until version 18. Write that answer down; it matters in the upgrade step.<\/p>\n\n\n\n
Next, list the extensions in every database and the PostgreSQL packages installed for 14. Each extension package, such as postgresql-14-postgis-3<\/span>, needs a matching 18 package before an in-place upgrade can work:<\/p>\n\n\n\n
for db in $(sudo -u postgres psql -Atc \"SELECT datname FROM pg_database WHERE datallowconn\"); do\n  echo \"== $db\"\n  sudo -u postgres psql -d \"$db\" -Atc \"SELECT extname || ' ' || extversion FROM pg_extension\"\ndone\ndpkg -l 'postgresql-14*' | grep ^ii<\/code><\/pre>\n\n\n\n
Then size and free space, plus any roles that still log in with MD5 hashes:<\/p>\n\n\n\n
sudo -u postgres psql -c \"SELECT datname, pg_size_pretty(pg_database_size(datname)) FROM pg_database ORDER BY pg_database_size(datname) DESC;\"\nsudo du -sh \/var\/lib\/postgresql\/14\/main\ndf -h \/var\/lib\/postgresql\nsudo -u postgres psql -Atc \"SELECT rolname FROM pg_authid WHERE rolpassword LIKE 'md5%';\"<\/code><\/pre>\n\n\n\n
Compare the du<\/span> figure with the free space from df<\/span>. If free space is smaller than the data directory, only link mode fits on this disk as it stands. Hostry VPS resources can be scaled up, so check whether the next plan’s disk covers a second copy; we would rather scale for the window than clear room on a live database server, where hurried deletions cause their own outages.<\/p>\n\n\n\n
Upgrade PostgreSQL 14 to 18 or stop at 17?<\/h2>\n\n\n\n
You can go from 14 straight to 18 without installing 15, 16 or 17 in between: the pg_upgrade documentation for version 18<\/a><\/strong> supports upgrades from 9.2.X and later, and a dump from 14 restores into 18 as well.<\/p>\n\n\n\n
Before you pick the target, do two checks. First, read “Migration to Version 18” in the PostgreSQL 18 release notes<\/a><\/strong> against your application. Two examples from that list: VACUUM<\/span> and ANALYZE<\/span> now also process inheritance children unless you add ONLY<\/span>, and COPY FROM<\/span> no longer treats \\.<\/span> as end-of-file in CSV files. Second, confirm every extension has an 18 package with apt-cache policy postgresql-18-postgis-3<\/span> (with your extension’s name) once the repository from step 1 below is added.<\/p>\n\n\n\n
If both checks pass, go to 18. It is supported until November 2030, a year longer than 17, and 18.6 is its sixth minor release. Two changes in 18 also make the upgrade itself easier: pg_upgrade<\/span> now carries most optimizer statistics over, and its database checks run in parallel under –jobs<\/span>. Pick 17 if an extension you depend on has no 18 package yet or the application is not ready for an 18 change.<\/p>\n\n\n\n
As of November 2, PostgreSQL 19 is at release candidate stage: RC 1 shipped on October 15, and the project plans general availability for November 19, 2026, a week after PostgreSQL 14 end of life. A .0 release is a poor target for a deadline upgrade. Once 19 has had a few minor releases, the step from 18 to 19 can be planned like any other maintenance job.<\/p>\n\n\n\n
Back up off the server and test the restore<\/h2>\n\n\n\n
Every rollback path below ends in “restore from backup” at some point, so make the backup before touching packages. Run these as your login user (examples use deploy<\/span> and appdb<\/span>; substitute your own). The shell redirect writes the files as that user, so postgres<\/span> needs no write access to your home directory:<\/p>\n\n\n\n
mkdir -p ~\/pg14-backup && chmod 700 ~\/pg14-backup\nsudo -u postgres pg_dumpall --globals-only > ~\/pg14-backup\/globals.sql\nsudo -u postgres pg_dump -Fc appdb > ~\/pg14-backup\/appdb.dump\nsudo -u postgres psql -d appdb -Atc \"SELECT count(*) FROM orders;\"\nrsync -av ~\/pg14-backup\/ deploy@203.0.113.10:pg14-backup\/<\/code><\/pre>\n\n\n\n
globals.sql<\/span> holds roles with their password hashes, so keep it as private as the dump. Repeat the pg_dump<\/span> line for each database, and keep the row counts of a few large tables to compare later. Swap 203.0.113.10<\/span> for your second machine.<\/p>\n\n\n\n
Before you rely on the backup, restore it on a second VPS<\/strong>. On that test server:<\/p>\n\n\n\n
  1. Install PostgreSQL 18 from the PGDG repository, as in step 1 below.<\/li>
  2. Keep port 5432 off the internet: leave listen_addresses<\/span> at its default localhost<\/span> and allow only SSH in the firewall, as in our UFW and SSH key setup for a fresh Ubuntu server<\/a><\/strong>.<\/li>
  3. Restore the globals, then the database, and compare the row count:<\/li><\/ol>\n\n\n\n
    sudo -u postgres psql -q < ~\/pg14-backup\/globals.sql\nsudo -u postgres pg_restore --create -d postgres < ~\/pg14-backup\/appdb.dump\nsudo -u postgres psql -d appdb -Atc \"SELECT count(*) FROM orders;\"<\/code><\/pre>\n\n\n\n
    An ERROR: role “postgres” already exists<\/span> line from the globals file is expected and harmless. Time the restore: it is the real downtime figure for the dump method on your data. Point a staging copy of the application at this server too.<\/p>\n\n\n\n
    pg_upgrade –link vs dump and restore<\/h2>\n\n\n\n
    Method<\/th>Downtime<\/th>Extra disk on the server<\/th>Rollback<\/th><\/tr><\/thead>
    Dump and restore (pg_upgradecluster<\/span> default)<\/td>The whole run; grows with data size, since every row is reloaded and every index rebuilt<\/td>A full second copy of the data in the new cluster<\/td>Old cluster untouched; drop the new one and start 14 again<\/td><\/tr>
    pg_upgrade<\/span> in copy mode<\/td>Time to copy the data files<\/td>A second copy of the data files<\/td>Old cluster untouched<\/td><\/tr>
    pg_upgrade –link<\/span><\/td>Mostly the schema dump and restore; data files are hard-linked<\/td>Little; both data directories must be on one filesystem<\/td>Only until the new cluster first starts; after that, from backup<\/td><\/tr>
    Logical replication to a second VPS<\/td>A switchover of several seconds, per the docs<\/td>None on the old server; the copy lives elsewhere<\/td>14 keeps running until you switch<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    \"Three
    The three main paths from PostgreSQL 14 to 18 and what each one costs in downtime, disk and rollback<\/figcaption><\/figure>\n\n\n\n
    For one VPS, our default is the dump method whenever the timed test restore fits inside your maintenance window. It is slower, the old cluster stays intact, and with postgresql-common it turns data checksums on in the 18 cluster. Use –link<\/span> when the database is too large for that window or the disk cannot hold a second copy, and accept that the backup is then your rollback.<\/p>\n\n\n\n
    –clone<\/span> would give link-mode speed while keeping the old cluster usable, but on Linux the pg_upgrade documentation lists only Btrfs and XFS created with reflink support. On an ext4 root disk, common on VPS images, the run errors out.<\/p>\n\n\n\n
    Logical replication is the near-zero-downtime option, and the upgrading chapter of the PostgreSQL manual<\/a><\/strong> describes it as a standby on the new version that you switch to once it catches up. Schema changes, sequence values and large objects are not replicated, so sequences must be moved forward on the new primary before the application writes to it, either from the publisher’s values or from the tables, for example SELECT setval(pg_get_serial_sequence(‘orders’, ‘id’), (SELECT max(id) FROM orders));<\/span> for each serial or identity column.<\/p>\n\n\n\n
    How to upgrade PostgreSQL 14 to 18 on Ubuntu or Debian<\/h2>\n\n\n\n
    On Ubuntu and Debian, upstream pg_upgrade<\/span> comes wrapped in pg_upgradecluster<\/span>, which also copies the configuration from \/etc\/postgresql\/14\/main<\/span>, moves the old cluster to a spare port and gives the new one the original port. Use it unless you built PostgreSQL yourself.<\/p>\n\n\n\n
    1. Add the PGDG repository and install PostgreSQL 18<\/strong><\/p>\n\n\n\n
    Ubuntu 22.04 and 24.04 do not ship 18, so take it from the project’s own apt repository, as the PostgreSQL download page for Ubuntu<\/a><\/strong> describes. The script adds the repository under \/etc\/apt\/sources.list.d\/<\/span> (as pgdg.list<\/span> on 22.04, pgdg.sources<\/span> on 24.04) and asks you to press Enter:<\/p>\n\n\n\n
    sudo apt install -y postgresql-common\nsudo \/usr\/share\/postgresql-common\/pgdg\/apt.postgresql.org.sh\nsudo apt install -y postgresql-18\npg_lsclusters<\/code><\/pre>\n\n\n\n
    Install the 18 builds of every extension package from your inventory in the same command. The package creates an empty 18\/main<\/span> cluster, which pg_lsclusters<\/span> now shows on the next free port, usually 5433.<\/p>\n\n\n\n
    2. Run the checks while 14 is still serving<\/strong><\/p>\n\n\n\n
    pg_upgradecluster –check<\/span> only confirms that every postgresql-14-*<\/span> package has an 18 counterpart. For the real compatibility checks, run upstream pg_upgrade –check<\/span> against an 18 cluster whose checksum setting matches the old one. With checksums off on 14, that means recreating 18\/main<\/span>:<\/p>\n\n\n\n
    sudo pg_dropcluster 18 main --stop\nsudo pg_createcluster 18 main -- --no-data-checksums\ncd \/tmp\nsudo -u postgres \/usr\/lib\/postgresql\/18\/bin\/pg_upgrade --check --link \\\n  -b \/usr\/lib\/postgresql\/14\/bin -B \/usr\/lib\/postgresql\/18\/bin \\\n  -d \/etc\/postgresql\/14\/main -D \/etc\/postgresql\/18\/main -p 5432\nsudo pg_dropcluster 18 main\nsudo pg_upgradecluster --check -v 18 14 main<\/code><\/pre>\n\n\n\n
    Leave out — –no-data-checksums<\/span> if 14 already had checksums on. -p<\/span> is the port of the running 14 cluster; the new cluster is started on pg_upgrade’s default 50432. The pg_upgrade run should end with *Clusters are compatible*<\/span>. The second pg_dropcluster<\/span> matters, because pg_upgradecluster<\/span> refuses to run, even with –check<\/span>, while 18\/main<\/span> exists.<\/p>\n\n\n\n
    3. Upgrade in the maintenance window<\/strong><\/p>\n\n\n\n
    Decide first whether you want a pause before 18 starts. pg_upgradecluster<\/span> starts the new cluster by default when 14 was running or upgrade hooks are present. With link mode, that first start ends the cheap rollback, so add –no-start<\/span> if you want to inspect the result before committing.<\/p>\n\n\n\n
    Then stop whatever writes to the database, take a fresh dump if data changed since the backup, and run one of these:<\/p>\n\n\n\n
    sudo systemctl stop myapp\n# dump method (default):\nsudo pg_upgradecluster -v 18 14 main\n# or link mode:\nsudo pg_upgradecluster -v 18 -m upgrade --link 14 main<\/code><\/pre>\n\n\n\n
    Per the pg_upgradecluster man page<\/a><\/strong>, the old cluster moves to another port with startup set to manual, and the new one takes port 5432 and starts. For the upgrade method, postgresql-common 293 creates the 18 cluster with –no-data-checksums<\/span> when 14 had none.<\/p>\n\n\n\n
    \"pg_upgradecluster
    What pg_upgradecluster does to ports and startup. After the dump method the old 14 cluster stays usable as a fallback; after link mode it is not, once 18 has started<\/figcaption><\/figure>\n\n\n\n
    4. Refresh statistics and extensions<\/strong><\/p>\n\n\n\n
    Current postgresql-common runs both vacuumdb<\/span> commands below from its analyze<\/span> hook when it starts the new cluster. Run them by hand only after –no-start<\/span> or a plain pg_upgrade run. The first fills in statistics pg_upgrade could not carry over, such as extended statistics, and the second updates the counters autovacuum relies on:<\/p>\n\n\n\n
    sudo -u postgres \/usr\/lib\/postgresql\/18\/bin\/vacuumdb --all --analyze-in-stages --missing-stats-only\nsudo -u postgres \/usr\/lib\/postgresql\/18\/bin\/vacuumdb --all --analyze-only<\/code><\/pre>\n\n\n\n
    Extensions are a separate step. With the upgrade method, pg_upgrade may leave update_extensions.sql<\/span> in the log directory, with lines such as ALTER EXTENSION “pgcrypto” UPDATE;<\/span>. Find it, apply it with sudo -u postgres psql -f<\/span> and the file’s path, then start the application:<\/p>\n\n\n\n
    sudo ls \/var\/log\/postgresql\/pg_upgradecluster-14-18-main.*\/<\/code><\/pre>\n\n\n\n
    Verify the upgrade before deleting anything<\/h2>\n\n\n\n
    pg_lsclusters\nsudo -u postgres psql -Atc \"SELECT version();\"\nsudo -u postgres psql -d appdb -Atc \"SELECT count(*) FROM orders;\"\nsudo tail -n 50 \/var\/log\/postgresql\/postgresql-18-main.log<\/code><\/pre>\n\n\n\n
    pg_lsclusters<\/span> should show 18 online on 5432 and 14 down on another port. Compare the row counts with the ones you saved, then have the application write a record and read it back.<\/p>\n\n\n\n
    If the MD5 query from the inventory returned roles, PostgreSQL 18 still accepts them, but MD5 is deprecated for removal in a future major, and setting an MD5 password now raises a warning. Reset those passwords while password_encryption<\/span> is at its default scram-sha-256<\/span>, then switch the matching pg_hba.conf<\/span> lines from md5<\/span> to scram-sha-256<\/span>.<\/p>\n\n\n\n
    Keep the old cluster for a few days if you used the dump method; it costs only disk. Then remove it and the 14 packages with sudo pg_dropcluster 14 main<\/span> and sudo apt purge ‘postgresql-14*’<\/span>. After link mode the old cluster is unusable anyway, so drop it once 18 has been checked.<\/p>\n\n\n\n
    If pg_upgrade fails<\/h2>\n\n\n\n
    The messages quoted below were reproduced with PostgreSQL 14.24, PostgreSQL 18.6 and postgresql-common 293.<\/p>\n\n\n\n
    Data checksums do not match<\/h3>\n\n\n\n
    pg_upgrade stops with old cluster does not use data checksums but the new one does<\/span> when the 18 cluster came from a default initdb<\/span>, which turns checksums on since version 18. Recreate it with –no-data-checksums<\/span> as in step 2. You can enable checksums later with sudo -u postgres \/usr\/lib\/postgresql\/18\/bin\/pg_checksums –enable -D \/var\/lib\/postgresql\/18\/main<\/span> while the cluster is stopped; it rewrites every block, so budget downtime for it.<\/p>\n\n\n\n
    Missing extension libraries<\/h3>\n\n\n\n
    Your installation references loadable libraries that are missing from the new installation<\/span> means a .so<\/span> file used by 14 has no 18 build. The message points to loadable_libraries.txt<\/span> under the new data directory, which names the library and the database.<\/p>\n\n\n\n
    Install the matching postgresql-18-*<\/span> package, or drop the extension on 14 if nothing uses it. Do not run CREATE EXTENSION<\/span> in the new cluster yourself, since pg_upgrade copies the definitions.<\/p>\n\n\n\n
    Cluster exists, port in use or server still running<\/h3>\n\n\n\n