Architecture
PostgreSQL 14 End of Life: 12 November 2026 and Your Upgrade Options
PostgreSQL 14 reaches end of life on 12 November 2026, when the community ships its final minor release and stops fixing it. The Amazon RDS and Azure dates, which version to move to, the three upgrade paths, what breaks most often, and how to move a production cluster to a supported version without a long outage.
Planning your PostgreSQL upgrade? Talk to a senior PostgreSQL DBA ↓By RadixTrie22 September 202610 min read
PostgreSQL 14 reaches end of life on 12 November 2026, when the PostgreSQL Global Development Group ships its final minor release; after that there are no further bug or security fixes for 14. The current minor is 14.24.
Managed services run on their own calendars. Amazon RDS for PostgreSQL 14 leaves standard support on 28 February 2027 and bills Extended Support from 1 March 2027. Azure Database for PostgreSQL lists 11 December 2026 as the end of standard support for 14, with paid Extended Support applied automatically after that. The supported targets are PostgreSQL 15, 16, 17 and 18.
Checked against the PostgreSQL versioning policy, the Amazon RDS for PostgreSQL release calendar and the Azure Database for PostgreSQL version policy on 16 October 2026. Updated 16 October 2026.
The PostgreSQL project supports each major version for five years. PostgreSQL 14 was released on 30 September 2021, so its final minor release is scheduled for 12 November 2026, after which it receives no further security or bug fixes. PostgreSQL 14 end of life is therefore not an event to react to in December; it is a deadline that decides what your production clusters should be running by the northern autumn. This article explains what changes, which version to move to, the three ways to upgrade, the things that most often go wrong, and how to sequence the work for a cluster that cannot be down for long.
PostgreSQL support dates
PostgreSQL 13: first release 24 September 2020; final release 13 November 2025; unsupported
PostgreSQL 14: first release 30 September 2021; final release 12 November 2026; supported for 27 more days on 16 October 2026 (current minor 14.24)
PostgreSQL 15: first release 13 October 2022; final release 11 November 2027; supported
PostgreSQL 16: first release 14 September 2023; final release 9 November 2028; supported
PostgreSQL 17: first release 26 September 2024; final release 8 November 2029; supported
PostgreSQL 18: first release 25 September 2025; final release 14 November 2030; supported
PostgreSQL 14: first release 30 September 2021; final release 12 November 2026; supported for 27 more days on 16 October 2026 (current minor 14.24)
PostgreSQL 15: first release 13 October 2022; final release 11 November 2027; supported
PostgreSQL 16: first release 14 September 2023; final release 9 November 2028; supported
PostgreSQL 17: first release 26 September 2024; final release 8 November 2029; supported
PostgreSQL 18: first release 25 September 2025; final release 14 November 2030; supported
Dates from the PostgreSQL versioning policy, which states that after five years 'a final minor version will be released and the software will then be unsupported (end-of-life)'. PostgreSQL 19 was at release-candidate stage on 16 October 2026 and is not yet a target for production.
PostgreSQL 14 on managed services
Amazon RDS for PostgreSQL 14: standard support ends 28 February 2027; Extended Support billed from 1 March 2027 (year 3 pricing from 1 March 2029); Extended Support ends 28 February 2030
Azure Database for PostgreSQL flexible server, 14: standard support ends 11 December 2026 on Azure's version policy page; servers still on 14 are then enrolled in paid Extended Support automatically, which Azure's Extended Support page runs to 11 November 2029
Self-managed PostgreSQL 14: final release 12 November 2026; no further releases of any kind
Azure Database for PostgreSQL flexible server, 14: standard support ends 11 December 2026 on Azure's version policy page; servers still on 14 are then enrolled in paid Extended Support automatically, which Azure's Extended Support page runs to 11 November 2029
Self-managed PostgreSQL 14: final release 12 November 2026; no further releases of any kind
Two Azure pages give slightly different dates for 14: the version policy (updated 15 September 2026) says Azure standard support ends on 11 December 2026, while the Extended Support page (updated 13 July 2026) shows 31 January 2027 with Extended Support from 1 February 2027. Plan for the earlier date and confirm your servers' status in the Azure portal, which flags servers approaching end of support. On Amazon RDS, older minors have their own dates: 14.18 and 14.19 leave RDS standard support on 31 October 2026, and the RDS release calendar has the major version following on 28 February 2027.
What end of life means for a PostgreSQL major version
Nothing stops working on the day. The cluster starts, queries run, backups complete. What stops is the supply of fixes: any vulnerability found after the final release stays open, and the extensions and drivers around PostgreSQL gradually drop the version from their test matrices. PostgreSQL 13 reached the same point on 13 November 2025. On 16 October 2026 the supported majors are 15, 16, 17 and 18, each with its own end date roughly five years after release, and the project normally ships a new major every autumn. If you are on 14, a move to a recent major buys the longest runway for a single project.
Which version to upgrade to
PostgreSQL 18 for the longest runway: it is supported until 14 November 2030, and its pg_upgrade transfers most optimizer statistics from the old cluster, which removes the slow first hours that earlier upgrades suffered. Choose 17 (supported to 8 November 2029) when an extension you depend on has not yet shipped a release for 18. Do not choose 15 unless a vendor forces it: it reaches end of life on 11 November 2027, twelve months after 14, and you would be doing this again next year. Whichever target you pick, pg_upgrade supports the direct jump from 14; there is no need to step through 15, 16 and 17.
The three upgrade paths
- pg_upgrade. The in-place tool that converts the data directory to the new version, usually in minutes with link mode, so downtime is short. It needs the new binaries installed alongside the old ones, a compatible set of extensions on the target, and a full backup you have actually restore-tested first, because it is not reversible once the old cluster is modified. With a target of 17 or earlier it does not carry planner statistics across, so the first hours after the upgrade need an ANALYZE run or performance will look worse than it is; from PostgreSQL 18 it transfers most optimizer statistics, and the documentation still asks for a vacuumdb --analyze-in-stages run afterwards for the ones it does not.
- Logical replication. Stand up the new cluster on the target version, replicate the tables into it while the old one keeps serving, then switch the application over when the two are in step. Downtime is measured in the time it takes to repoint connections. It costs more setup, sequences and DDL need handling separately, and large tables take time to copy, but it is the route for clusters where an hour of downtime is not available and the rollback must be trivial.
- Dump and restore. pg_dumpall or pg_dump followed by a restore into the new cluster. The simplest path and the one with the longest outage, proportional to the size of the data. Appropriate for smaller databases, for consolidating several old clusters into one, or when the operating system and hardware are being replaced at the same time.
What breaks most often
Extensions first. PostGIS, TimescaleDB, pg_partman, pg_cron and the rest each need a version that supports the target major, and some require their own upgrade step after PostgreSQL moves. Check every extension in every database before choosing a target version. Second, collations: if the operating system or its C library changes as part of the move, text indexes built under the old collation can silently return wrong results until they are rebuilt, so plan a REINDEX where the platform changes. Third, drivers and ORMs pinned to an old protocol or to removed server behaviour; run the real application against a copy on the new version rather than trusting release notes. Fourth, the performance surprise described above when statistics are missing after a pg_upgrade to 17 or earlier. Finally, managed services: Amazon RDS and Azure run the calendars above, bill for Extended Support once standard support ends, and stop offering the old minors for new instances, so the community date is not the one that costs money.
The one habit that prevents nearly every upgrade incident is rehearsal: restore a recent backup onto the target version, run the application and the heaviest reports against it, time the cutover, and practise the rollback before touching production.
A plan that fits a production cluster
Inventory every PostgreSQL 14 cluster with its size, extensions, replication topology and the applications that connect to it. Choose one target major for the estate unless something forces an exception. Pick the upgrade path per cluster from the downtime you can afford, not from habit: pg_upgrade for most, logical replication for the ones that cannot stop, dump and restore for the small or the consolidating. Rehearse on a copy, fix what breaks, then schedule production with the rollback written down. Afterwards, refresh statistics, watch the slow-query log for a week, and confirm backups and replicas are healthy on the new version before decommissioning the old one.
PostgreSQL 14 end of life: common questions
When is PostgreSQL 14 end of life?
12 November 2026. The PostgreSQL versioning policy lists that date as the final release for 14. The policy is five years of support from the first release, which for 14 was 30 September 2021, then one final minor version, after which the version is, in the project's words, 'unsupported (end-of-life)'.
Is PostgreSQL 14 still supported?
Yes, until 12 November 2026. The current minor is 14.24, released in August 2026; one more minor ships on 12 November 2026 and that is the last. Managed services extend the date for a fee: Amazon RDS keeps 14 under standard support to 28 February 2027 and bills Extended Support after that, and Azure enrols servers still on 14 in paid Extended Support automatically once its standard support ends.
Will PostgreSQL 14 stop working on 12 November 2026?
No. The cluster starts, queries run and backups complete. What stops is the supply of fixes: any bug or vulnerability found after the final release stays open, extensions and drivers drop 14 from their test matrices, and auditors and insurers treat an unsupported database engine as a finding. The practical deadline is set by those people, not by the software.
Can we upgrade directly from PostgreSQL 14 to 18?
Yes. The pg_upgrade documentation states that it 'supports upgrades from 9.2.X and later to the current major release', so 14 to 18 is one step. Check every extension for an 18 release first, take a restore-tested backup, rehearse on a copy, and run the vacuumdb --analyze-in-stages commands the tool prints at the end. Logical replication and dump-and-restore also go straight to 18.
What happens to PostgreSQL 14 on Amazon RDS after 12 November 2026?
It keeps running under RDS standard support until 28 February 2027. From 1 March 2027 RDS bills Extended Support, with year 3 pricing from 1 March 2029, until Extended Support ends on 28 February 2030, per the RDS release calendar. The older minors go first: 14.18 and 14.19 leave standard support on 31 October 2026. Plan the major version upgrade before March 2027 unless you want to pay for the delay.
What happens to PostgreSQL 14 on Azure?
Azure's version policy ends standard support for 14 on 11 December 2026 (its Extended Support page shows 31 January 2027; plan for the earlier date). After that no new servers can be created on 14, and servers still on 14 are enrolled automatically in paid Extended Support, which covers security patches and critical bug fixes only, runs to 11 November 2029, and stops only when you upgrade. Azure supports in-place major version upgrades to the versions it currently supports.
Which version should we upgrade to?
PostgreSQL 18 by default: the longest runway (to 14 November 2030) and a pg_upgrade that carries most optimizer statistics across. PostgreSQL 17 when an extension you need has not yet been released for 18. Not 15, which ends on 11 November 2027, unless an application vendor leaves you no choice; then write down when you expect that to change.
What is the final PostgreSQL 14 release?
On 16 October 2026 the current minor is 14.24. The final minor is scheduled for 12 November 2026, and this answer will be updated with its number on the day. Apply it, because it is the last fix 14 will ever receive, and then treat the version as unsupported: the next vulnerability stays open for good.
How RadixTrie helps
This is bread-and-butter work for a senior PostgreSQL DBA and a distraction for everyone else. Our PostgreSQL DBA services cover exactly this: senior engineers who plan and run PostgreSQL upgrades for organisations wherever they are, through our remote DBA services, and who can stay on afterwards to run the cluster under a fixed monthly retainer. In South Africa, see PostgreSQL support in South Africa. Two anonymised examples of the work: a 30 TB Postgres database reduced to 13 TB and PostgreSQL performance stabilised. If the reason you are on PostgreSQL at all is a move away from Oracle, our guide to Oracle to PostgreSQL migration covers that road, and database high availability and disaster recovery explains how to make the upgraded cluster resilient. Every one of our database services is delivered by the engineer who does the work, with no service desk in between.
Related reading: PostgreSQL Support in South Africa: Running Postgres in Production Without the Guesswork · Oracle to PostgreSQL Migration: What Actually Takes the Time · High Availability and Disaster Recovery: Tested Beats Configured · The Database Health Check: What a Good One Covers and What It Finds
Planning your PostgreSQL upgrade?
Tell us what you run today and when it has to move. A senior PostgreSQL DBA will reply directly, usually within one working day. Prefer email or phone? Write to expert@radixtrie.com or call +27 10 143 0304.
TAGSPostgreSQLPostgreSQL 14UpgradeEnd of Life