PostgreSQL 14 end of life on 12 November 2026: which version to upgrade to

PostgreSQL 14 receives its final minor release on 12 November 2026. After that date, the PostgreSQL community no longer publishes any fix for this version, neither security nor bug fixes. This guide gives the exact dates, what end of life changes, the deadlines at AWS, Azure and Google Cloud, the version to upgrade to and how to do it without unpleasant surprises.

It is written for technical leaders, CIOs and application owners whose database still runs on PostgreSQL 14, on their own servers or with a hosting provider. Database upgrades are part of our infrastructure, DevOps and web security offer.

When does PostgreSQL 14 support end?

Community support for PostgreSQL 14 ends on 12 November 2026, the day of its final minor release. The rule has been known since the version came out on 30 September 2021: the PostgreSQL Global Development Group supports each major version for five years, then publishes a final minor release, after which the version is unsupported.

Until then, each supported major version receives a minor release at least every three months, fixing bugs, security vulnerabilities and data corruption issues. The latest PostgreSQL 14 minor release to date is 14.24, of 13 August 2026; the next one, scheduled for 12 November 2026, will be the last.

PostgreSQL 13 has been unsupported since 13 November 2025: a database still on version 13, or older, is in the same situation, one year ahead.

What happens after PostgreSQL 14 end of life?

After 12 November 2026, a PostgreSQL 14 database keeps running normally, but no vulnerability discovered afterwards will be fixed for it. Nothing stops on 13 November: the risk grows, as vulnerabilities fixed in versions 15 to 18 remain open in version 14.

The community says so in its versioning policy: it considers applying minor releases less risky than staying on an old one, and recommends always running the current minor release of your major version. A version that no longer gets any falls outside that framework.

• Security. A vulnerability published after 12 November 2026 that also affects version 14 will stay open, unless a provider offers extended support.
• The tools around the database. New features no longer target retired versions: at Azure, for example, new extensions are not offered for a version the community has retired.
• Your clients’ and auditors’ requirements. If a contract, a client or a security audit requires supported components, a version 14 database becomes a gap to justify.
• The upgrade itself. The wider the gap between the running version and the target, the more release notes to read and changes to test.

The logic is the same as for a programming language reaching end of life: our article on the end of support for PHP 8.2 describes the same approach on the code side.

PostgreSQL 14 on AWS, Azure or Google Cloud: which dates?

With the major managed database providers, PostgreSQL 14 stays covered a few weeks longer than in the community, then moves to extended support, paid at AWS and Google Cloud. Here are the dates found in their documentation on 4 November 2026:

Azure states that once the community retires a version, it stops applying patches to the database engine, while still maintaining the host and the infrastructure. It also reserves the right to stop a server exposed to a critical vulnerability until it is upgraded.

Extended support buys time, not a solution: you pay for it as long as the database stays on version 14, and it ends too. For a database on your own servers or with a traditional host, the date to remember remains 12 November 2026: after it, no more public fixes.

Which PostgreSQL version should you upgrade to?

To leave PostgreSQL 14, the preferred target is PostgreSQL 18: it is the most recent stable version, released on 25 September 2025, and it will be supported until 14 November 2030.

• PostgreSQL 18, the default choice. Supported until 14 November 2030. Its pg_upgrade tool now preserves optimizer statistics, which reduces the work after the upgrade (extended statistics still need to be rebuilt).
• PostgreSQL 17, if a component requires it. When an extension, a driver or a tool the application depends on is not yet validated on version 18. Supported until 8 November 2029.
• PostgreSQL 15 or 16, to avoid as a target. Version 15 ends on 11 November 2027, version 16 on 9 November 2028: the same upgrade would have to be done again in one or two years.
• PostgreSQL 19, not just yet. Its first release candidate came out on 15 October 2026 and general availability is planned for 19 November 2026, unless delayed. A freshly released version is tested before it carries production: for an upgrade to run now, 18 remains the sensible choice.

The PostgreSQL documentation allows it: you can upgrade from one major version to another without installing the intermediate versions, as long as you read the release notes of every version you skip, that is versions 15, 16, 17 and 18 for a move from 14 to 18.

How do you upgrade from PostgreSQL 14 to PostgreSQL 18?

A major version upgrade is not done like a minor update: the data file format changes. You either export and reload the database, convert its files with pg_upgrade, or go through logical replication. The choice depends mainly on the size of the database and the acceptable downtime.

On AWS, Azure or Google Cloud, the major version upgrade is started from the provider’s service, but the preparation and the tests stay the same. The steps, in order:

• Take stock. Exact version, database size, installed extensions and their versions, drivers used by the application, backup and monitoring scripts. A quick audit of the existing setup answers these questions.
• Choose the target version and the method. Check that each extension exists for the target version: pg_upgrade cannot check the compatibility of external modules.
• Prepare a staging environment. A copy of the database on version 18, with the application running its tests against it. If the copy contains personal data, read our article on test data and the GDPR.
• Run pg_upgrade in check mode. The --check option changes no data and lists the adjustments needed; it can run while the old server is still up.
• Test the application. Critical user journeys, scheduled jobs, backups and their restoration, and the response time of the heaviest queries.
• Back up and plan the rollback. A full backup, restored at least once, and a written procedure to roll back if the switchover fails.
• Upgrade production, then monitor. In a window announced to users; afterwards, rebuild the statistics that were not carried over, update the extensions, and watch the logs and response times.

What changes between PostgreSQL 14 and PostgreSQL 18?

The release notes of versions 15 to 18 each list their incompatibilities. Four of them affect the day-to-day running of a database: permissions, backups, storage and passwords.

• Permissions on the public schema (version 15). By default, users can no longer create objects in the public schema of a new database. An upgraded database keeps its original permissions, but a database created after the upgrade follows the new rule: an install script that creates tables with an account that does not own the database may fail.
• Exclusive backup (version 15). The old exclusive backup mode is removed, and the functions pg_start_backup() and pg_stop_backup() become pg_backup_start() and pg_backup_stop(). Home-made backup scripts that call them need reviewing.
• Data checksums (version 18). A new server is now created with data checksums enabled. pg_upgrade requires matching settings on both sides: create the target server with the --no-data-checksums option if the old one had none, or enable them on the old one first.
• MD5 passwords (version 18). MD5 password authentication is deprecated and will be removed in a future version; version 18 emits a warning whenever an MD5 password is set. Now is the time to move accounts to SCRAM-SHA-256.

Also read the “Migration” section of the version 16 and 17 release notes: each lists its own behaviour changes, to check against your application’s queries and settings. A database left un-upgraded for a long time often hides other delays, in the code as in the infrastructure: it is part of technical debt.

Frequently asked questions

PostgreSQL 14: set the upgrade date now

12 November 2026 breaks nothing, but it opens a period in which every vulnerability discovered stays open on PostgreSQL 14. The decision comes down to three points: the target version (18, or 17 if a component requires it), the method, and a switchover date set after a rehearsal on staging.

The iones team prepares and runs PostgreSQL database upgrades, from the inventory to production, as part of its infrastructure, DevOps and web security offer, and keeps them up to date over time with application maintenance. To review your databases, write to us.