PostgreSQL 14 Reaches End of Life on November 12

What Happens on November 12

PostgreSQL 14 reaches the end of its five years of community support on Thursday, November 12, 2026. That day the PostgreSQL project ships its regular quarterly minor releases, and PostgreSQL 14 gets one last update along with the newer versions. After that, no more bug fixes and no more security fixes come from the project for the 14 line.

Nothing stops working on Friday. A PostgreSQL 14 server keeps running exactly as it did, and there is no switch that turns it off. What ends is the stream of fixes. The next flaw found in PostgreSQL will be patched in 15, 16, 17 and 18, and 14 will stay as it is.

The good news is that this is one of the easier major upgrades to plan. PostgreSQL 18 is mature, with six minor releases behind it and support until November 2030. pg_upgrade can move a 14 cluster straight to 18 without stopping at the versions in between, and the managed platforms give extra time. Amazon RDS keeps PostgreSQL 14 on standard support until February 28, 2027. So this is a planning date, not an emergency.

Where Each PostgreSQL Version Stands

The project releases minor updates on the second Thursday of February, May, August and November, and November 12 is the next of them. Minor updates are drop-in. A restart on the new binaries is enough, with no dump and no pg_upgrade, which is why a server on an old minor release of a supported version is a quick fix while a server on an unsupported version is a project.

PostgreSQL 19 is close as well. Its first release candidate came out on October 15, a second is planned for November 12, and the project's target for general availability is November 19, 2026, unless a problem turns up and needs another candidate.

Which Version to Move To

For most production databases leaving 14 this month, PostgreSQL 18 is the sensible target. It has been out since September 2025, its sixth minor release fixed what the early adopters found, and it buys four years before the next upgrade has to happen.

PostgreSQL 17 is a reasonable choice when an extension or a tool you depend on has not certified 18 yet, which is worth checking for anything outside the core, such as a monitoring agent, a backup tool or a less common extension. It is supported until November 2029.

PostgreSQL 19 will be tempting once it ships on November 19. For a database that matters, it is usually better to let a new major version collect a minor release or two first. Moving from 14 to 18 now beats sitting on an unsupported 14 while 19 settles. Jumping to 15 or 16 makes little sense today, because 15 has only a year of support left and you would repeat this exercise in 2027.

If You Run It on Amazon RDS or Ubuntu

On Amazon RDS for PostgreSQL, the dates are different from the community ones. AWS keeps PostgreSQL 14 on standard support until February 28, 2027. From March 1, 2027, a database still on 14 moves to RDS Extended Support, which is charged on top of the instance price, with higher year-three pricing from March 1, 2029, and the final end on February 28, 2030. AWS continues to ship security fixes during Extended Support, so the price of waiting is the surcharge, not exposure. Those three and a half months are a good window to test the upgrade on a snapshot and schedule it without paying the surcharge.

On Ubuntu 22.04, apt install postgresql installs PostgreSQL 14, and the package in jammy-updates is 14.24 at the time of writing. Ubuntu follows the upstream minor releases for this package, so after November 12 any further fixes would have to come from Canonical's own work, since the PostgreSQL project stops. If a database relies on the distribution package, watch the Ubuntu security notices for postgresql-14 instead of assuming the updates continue. The PostgreSQL project's own apt repository carries every supported version for Ubuntu and Debian, which is the usual way to run 18 on a 22.04 server.

Three Ways to Upgrade

pg_upgrade is the standard route for a self-managed server. It converts the system catalogs and reuses the data files, so it is fast even for large databases. The --check option runs every compatibility test without changing anything, and it is the first thing to run. With --link the new cluster uses hard links to the old data files instead of copying them, which takes minutes rather than hours, but the old cluster cannot be started again once the new one has run. Take a backup first.

/usr/lib/postgresql/18/bin/pg_upgrade \
  --old-bindir=/usr/lib/postgresql/14/bin \
  --new-bindir=/usr/lib/postgresql/18/bin \
  --old-datadir=/var/lib/postgresql/14/main \
  --new-datadir=/var/lib/postgresql/18/main \
  --check

The paths above are the Debian and Ubuntu layout. On Debian and Ubuntu, the pg_upgradecluster wrapper from postgresql-common does the same job and handles the configuration files too.

Dump and restore with pg_dump or pg_dumpall is the simplest and slowest. It suits small databases where an hour of downtime is acceptable, and it rebuilds every index on the way.

Logical replication keeps the downtime to the moment you switch the application over. The new server is built on 18, receives the data from the old one while it keeps running, and takes over when it has caught up. It takes more preparation, and sequences, large objects and schema changes need care. We wrote it up step by step in how to upgrade PostgreSQL major versions with almost no downtime.

Changes Between 14 and 18 That Catch People

Four major versions of release notes are a lot to read. These are the ones most likely to break a real upgrade.

• The public schema. From PostgreSQL 15, new databases no longer let every user create objects in the public schema. An upgraded cluster keeps its old permissions, but a database created fresh on 18 for a restore does not, and an application user that used to create tables there gets a permission error.
• Old backup scripts. PostgreSQL 15 removed the exclusive backup mode, so pg_start_backup() and pg_stop_backup() no longer exist. They are now pg_backup_start() and pg_backup_stop(). Home-grown backup scripts from the 9.x era are the usual victims, and they fail quietly if nobody reads their output.
• Checksums. From PostgreSQL 18, initdb turns data checksums on by default. pg_upgrade needs the old and new clusters to match, and most 14 clusters were created without checksums, so create the new cluster with --no-data-checksums or pg_upgrade refuses to continue.
• MD5 passwords. PostgreSQL 18 still accepts them but warns when one is set, and the project has said support will be removed in a future major version. This is a good moment to move roles to SCRAM.

PostgreSQL 18 also asks for a reindex of full-text search and pg_trgm indexes after the upgrade on clusters that use the ICU or builtin collation providers, and it requires primary and foreign keys to use compatible collations. Both are rare, but the second one makes the restore fail outright, so it is better found in a test run.

A Short Checklist Before the Window

SELECT version();
SHOW data_checksums;
SELECT extname, extversion FROM pg_extension ORDER BY 1;

The first query confirms what you are upgrading from. The second tells you whether the new cluster needs --no-data-checksums. The third lists every extension, and each one must be installed for 18 on the new server before pg_upgrade will run. Then search your backup and maintenance scripts for pg_start_backup, run pg_upgrade with --check, and do one full rehearsal on a copy of production with the application pointed at it. A rehearsal finds the extension that was never packaged for 18 or the report query that relied on old behaviour, while it is still cheap to fix.

After the Switch

PostgreSQL 18 made the first hours after a pg_upgrade noticeably calmer. Earlier versions threw away the planner statistics during the upgrade, so the new cluster ran its first queries blind until ANALYZE had been through every table, and a busy application could feel slow for a while. Since 18, pg_upgrade keeps the ordinary statistics. Extended statistics, the ones created with CREATE STATISTICS, are still not carried over, so a short follow-up run is worth it.

vacuumdb --all --analyze-in-stages --missing-stats-only

The --missing-stats-only option is new in 18 as well. It only analyses what is missing, so on a large database it finishes in a fraction of the time a full pass would take. It needs a superuser.

Two other pg_upgrade improvements in 18 shorten the window itself. The checks now run in parallel when you pass --jobs, and the new --swap mode moves the data directories into place instead of copying or linking files, which the release notes describe as potentially the fastest option. Like --link, it leaves the old cluster unusable once the new one has started, so the backup comes first either way.

Then keep the old binaries and the backup for a few days, watch the slow query log, and remove the 14 packages once the application has run through a normal week, including any monthly jobs, on the new version.

What This Means for Your Team

If your databases are already on 15 or newer, nothing changes this week beyond installing the November 12 minor release. If anything still runs 14, the date is a prompt to plan. It is not a reason to panic. Pick 18 as the target, rehearse once, and schedule the move for a quiet evening. On RDS you have until February 28, 2027 before Extended Support charges begin.

We do these upgrades as part of our migration services, from the rehearsal to the switch-over, for teams that would rather not spend a weekend on release notes.

Sources

• PostgreSQL versioning policy and support dates
• PostgreSQL release roadmap
• PostgreSQL 19 RC 1 announcement
• PostgreSQL 15 release notes, migration section
• PostgreSQL 18 release notes, migration section
• pg_upgrade documentation
• Amazon RDS for PostgreSQL release calendar
• Amazon RDS Extended Support