PostgreSQL 14 Reaches End of Life on 12 November 2026: What To Do Now

November 2026 is a busy month for PostgreSQL. On 12 November the project ships the final update for PostgreSQL 14, and from then on version 14 receives no more security or bug fixes. One week later, on 19 November, PostgreSQL 19 is scheduled to become generally available. If any of your databases still run on 14, this is the moment to plan the upgrade rather than discover the deadline in a security audit.

What "end of life" actually means

PostgreSQL supports each major version for five years. According to the official versioning policy, PostgreSQL 14 was first released on 30 September 2021 and its final release is due on 12 November 2026. After that date:

• No more security fixes. Vulnerabilities found after November are fixed in 15–19, not in 14.
• No more bug fixes. Data-corruption and crash fixes stop as well — this is the less visible but often more important part.
• The ecosystem moves on. Extensions, drivers, backup tools and managed services gradually drop support for unsupported versions. Cloud providers typically move unsupported engines to paid extended support or force an upgrade on their own schedule.

Your database will not stop working on 13 November. But every month after that the risk grows, and compliance frameworks such as ISO 27001 or NIS2-driven audits increasingly treat unsupported software as a finding.

Where to go: PostgreSQL 18 now, or 19 in a few weeks?

PostgreSQL 19 RC 1 was released on 15 October 2026, a second release candidate is planned for 12 November, and general availability is planned for 19 November. That makes the choice of target version a real question:

• Upgrade to PostgreSQL 18 now if you need to be on a supported version soon, rely on extensions or a managed service that may take a few months to support 19, or simply prefer a release that already has a year of minor-version fixes behind it. PostgreSQL 18 is supported until November 2030.
• Target PostgreSQL 19 if your upgrade project is starting now anyway and will take a few months of testing. By the time you are ready to cut over, 19 will have its first minor releases, and you buy yourself an extra year of support compared with 18.
• Avoid the "two hops" trap. Upgrading 14 → 15 just to be supported, and then again next year, doubles the work. A major upgrade costs roughly the same whether you skip one version or four, so jump straight to the version you want to stay on.

Choosing the upgrade method

There are three established ways to move between major versions. The PostgreSQL release announcement itself names the first two:

• pg_upgrade with --link — fast, typically minutes of downtime regardless of database size, but it needs both versions installed on the same host and careful planning for a rollback.
• pg_dump / pg_restore — simple and clean, but downtime grows with data volume. Realistic only for smaller databases.
• Logical replication — build a new cluster on the target version, replicate into it, and switch over. Downtime drops to seconds or minutes and the old cluster stays as a fallback, at the price of more preparation (sequences, DDL changes, large objects).

We cover each method in detail in our major version upgrade guide, and the near-zero-downtime approach in zero-downtime PostgreSQL migrations.

A two-week checklist for teams still on 14

1. Inventory. List every PostgreSQL 14 instance, including the forgotten ones: reporting replicas, internal tools, staging databases that quietly became production.
2. Check extensions. Run SELECT extname, extversion FROM pg_extension; on each database and confirm every extension has a build for your target version.
3. Read the release notes of every version you are skipping (15, 16, 17, 18 and possibly 19) for incompatibilities that touch your workload.
4. Test on a copy of production. Restore a recent backup, upgrade it, and replay real queries. Compare plans and timings for your top queries from pg_stat_statements.
5. Decide the rollback path before you schedule the window, not during it.
6. After the upgrade, run ANALYZE on the whole database — optimizer statistics are not carried over by pg_upgrade — and watch performance closely for the first days.