PostgreSQL 14 Reaches End of Life on November 12. The Cloud Extended Support Meter Starts Soon After.

What Actually Happens on November 12?

PostgreSQL has one of the most predictable support policies in infrastructure software. According to the PostgreSQL versioning policy, the PostgreSQL Global Development Group supports a major version for 5 years after its initial release, then publishes a final minor version, and the software becomes unsupported. PostgreSQL 14 was first released on September 30, 2021. The same page lists its final release date as November 12, 2026.

That date matters most for teams that run PostgreSQL themselves: on virtual machines, on bare metal, or in Kubernetes with an operator. After November 12, a newly discovered vulnerability in PostgreSQL 14 will not get a community patch. Your Linux distribution may backport some fixes for a while, depending on its own lifecycle, but that is a separate promise with its own end date, and it rarely covers everything a database needs.

It is worth being precise about what does not happen. Nothing stops working on November 13. Queries still run, backups still restore, and your application does not notice. That is exactly why end of life is easy to ignore. The risk is not a failure on the day; it is that every month after it, you are one CVE away from an emergency upgrade on someone else's schedule.

The versioning policy also makes a point many teams skip: the community considers minor upgrades less risky than running an old minor version, and recommends always running the current minor release of your major version. If your PostgreSQL 14 fleet is not on the latest 14.x today, that is the first fix, and it takes minutes rather than weeks. The final 14.x release in November should be applied as well, because it is the last set of fixes that version will ever receive.

Your Cloud Provider Gave You a Grace Period. It Has a Meter.

Most companies do not run PostgreSQL themselves any more. They run it on Amazon RDS or Aurora, Azure Database for PostgreSQL, or Google Cloud SQL. All three providers have made the same decision about end-of-life versions: keep them running, keep patching critical issues, and charge for it. All three also enrol your databases automatically, which means doing nothing is a choice with a price attached.

On AWS, the RDS for PostgreSQL release calendar lists February 28, 2027 as the RDS end of standard support date for PostgreSQL 14, with Extended Support year 1 pricing from March 1, 2027, year 3 pricing from March 1, 2029, and the end of Extended Support on February 28, 2030. AWS's Extended Support documentation adds the part that matters at the end: if you still have not upgraded after Extended Support, Amazon RDS will upgrade the major version for you.

On Azure, Microsoft's extended support page for Azure Database for PostgreSQL lists December 11, 2026 as the Azure standard support end date for PostgreSQL 14, with extended support starting February 1, 2027 and ending November 11, 2029. The FAQ on the same page is unusually blunt: you cannot opt out of extended support, and the only way to stop the charges is to upgrade to a supported version. Azure started billing for versions 11 to 13 on September 1, 2026, so this is not a hypothetical future policy.

On Google Cloud, the Cloud SQL database version table shows extended support for PostgreSQL 14 starting February 1, 2027, with a deprecation date of February 1, 2030. Google's extended support documentation describes the charge as priced per vCPU per hour for dedicated-core instances, billed on top of normal instance pricing for every second the instance runs.

What Does Waiting Actually Cost?

Extended support prices look small per unit, which is how they end up on invoices nobody questions. The RDS for PostgreSQL pricing page lists Extended Support in US East (N. Virginia) at $0.100 per vCPU-hour in years 1 and 2, rising to $0.200 per vCPU-hour in year 3. AWS's charges documentation confirms that the fee also applies to standby instances in Multi-AZ deployments.

Here is our own illustrative arithmetic at that list price. A single production database on an 8-vCPU instance with Multi-AZ is 16 billable vCPUs. At $0.100 per vCPU-hour over roughly 730 hours a month, that is about $1,168 a month, or about $14,000 a year, for one database, before read replicas. In year 3 the same database costs about $2,336 a month in extended support alone. Multiply by staging, by reporting replicas and by the other services in the estate, and a typical mid-sized SaaS company can spend more on the privilege of not upgrading than the upgrade itself would cost.

The fee is only the visible part. Extended support, by each provider's own description, covers security fixes and critical bugs. It does not bring new features or performance improvements, and on Azure it explicitly excludes support for minor version upgrades. Meanwhile, the ecosystem moves on: new releases of ORMs, drivers, extensions and monitoring tools gradually drop testing against 14, and your team keeps paying the cost of a version that everything else is leaving behind.

There is also a trap in the escape hatch. AWS lets you disable Extended Support enrolment at any time, but its documentation states that if you disable it on an instance that is already past its standard support end date, the instance automatically upgrades to the next supported major version. That is an unrehearsed major upgrade triggered by a billing setting. It is the scenario the rest of this article is designed to avoid.

Which Version Should You Target: 16, 17 or 18?

Upgrading from 14 to 15 is the smallest step, and the wrong one. The versioning policy lists November 11, 2027 as the final release of PostgreSQL 15, so you would repeat this project in a year. PostgreSQL 16 buys time until November 2028. For most teams, the real choice is between 17 and 18, which are supported until November 2029 and November 2030 respectively.

PostgreSQL 17 is the conservative, high-value target. The PostgreSQL 17 release announcement describes a new internal memory structure for vacuum that consumes up to 20x less memory, and up to 2x better write throughput for high-concurrency workloads from write-ahead log improvements. It also adds JSON_TABLE, which lets teams query JSON documents as relational rows. For write-heavy systems that have fought autovacuum for years, 17 alone can justify the upgrade.

PostgreSQL 18 goes further. The PostgreSQL 18 release announcement introduces an asynchronous I/O subsystem, with benchmarking showing gains of up to 3x in certain scenarios, plus OAuth authentication, a native uuidv7() function for timestamp-ordered keys, and virtual generated columns. Most relevant to this project, pg_upgrade in 18 can keep planner statistics through a major upgrade, so the database reaches expected performance faster after cutover.

The deciding factor is usually the platform and the extensions, not the feature list. Check that your managed service offers the target version in your region, that every extension you depend on (PostGIS, pgvector, TimescaleDB, pg_partman and so on) supports it, and that your drivers and ORM versions are tested against it. If all of that is in place for 18, go to 18. If not, 17 is an excellent landing point, and it has one lasting advantage: the PostgreSQL 17 release notes state that pg_upgrade migrates valid logical replication slots and subscriptions, but only from old clusters on version 17 or later. Getting to 17 makes every future upgrade easier.

The Breaking Changes Hiding Between 14 and 18

A jump across four major versions collects four sets of incompatibilities. Most applications will not hit many of them, but the ones they do hit tend to surface late, in CI or in production, unless someone reads the release notes deliberately. These are the ones we see matter most in real application code.

Schema permissions changed in 15. The PostgreSQL 15 release notes remove PUBLIC's CREATE permission on the public schema for new clusters and newly created databases. An upgraded cluster keeps its existing permissions, so production often looks fine. The breakage shows up elsewhere: a fresh test database in CI, a new tenant database, or a developer's local container where a migration user suddenly cannot create tables. The same release renamed pg_start_backup() and pg_stop_backup() to pg_backup_start() and pg_backup_stop(), removed exclusive backup mode, and removed plpython2u. Old backup scripts and forgotten Python 2 functions are classic upgrade blockers.

Version 17 tightened search_path during maintenance. Its release notes say that operations such as ANALYZE, CREATE INDEX, REINDEX, VACUUM and REFRESH MATERIALIZED VIEW now use a safe search_path, so functions used in expression indexes and materialized views that reference non-default schemas must specify a search path. Teams that built expression indexes on helper functions years ago can discover this when a nightly REINDEX fails. Version 17 also removed the old_snapshot_threshold setting and the adminpack extension.

Version 18 has several changes worth planning for. The PostgreSQL 18 release notes make data checksums the initdb default, and note that pg_upgrade requires matching checksum settings, so self-managed clusters without checksums need the new --no-data-checksums option on the target. MD5 password authentication is deprecated, with removal planned for a future major release, which makes this the right upgrade to move roles to SCRAM. COPY FROM no longer treats a lone backslash-dot as end of file in CSV mode, and AFTER triggers now run as the role that was active when the event was queued.

Extensions deserve their own line in the plan. Microsoft's extended support FAQ notes that on Azure, non-core extensions such as pgvector and TimescaleDB are not upgraded automatically during a major version upgrade and need ALTER EXTENSION ... UPDATE or recreation afterwards. If your product now depends on pgvector for search or AI features, as many do after the consolidation trend we covered in vector databases versus pgvector, rebuild and benchmark those indexes as part of the rehearsal, not after cutover.

Picking an Upgrade Path: In-Place, Blue/Green or Logical Replication

There are three realistic ways to move a production database from 14 to 17 or 18, and the right one depends on how much downtime the business will accept and how large the database is.

The simplest is an in-place major version upgrade using pg_upgrade, which every managed provider wraps in a single console action. It is reliable and well understood, but the database is unavailable for the duration, and on older versions the planner starts with no statistics, so performance is poor until ANALYZE completes. PostgreSQL 18 improves this path with preserved statistics, parallel checks through --jobs, and a new --swap mode for faster directory handling. For internal tools, small databases or systems with a real maintenance window, in-place is often the right answer.

For customer-facing systems on AWS, blue/green deployments are the default we recommend. AWS's blue/green deployment overview describes creating a synchronised green copy of production, upgrading the engine there, testing it, and switching over, which typically takes under a minute with no data loss and no application changes. The same page notes that under certain conditions RDS for PostgreSQL uses logical replication to keep the green environment in sync, which brings logical replication's own constraints on DDL and tables without primary keys into scope.

The third option is a hand-built logical replication migration: create a new cluster on the target version, replicate from 14, validate, and move traffic. It gives the most control and the smallest cutover window, and it is the only approach that also works when you are changing providers, instance families or regions at the same time. It also demands the most engineering: sequences to synchronise, large objects that logical replication does not carry, DDL freezes during the migration, and a tested rollback. It is a good fit for a team that has done it before, and a risky first project for a team that has not.

A Ten-Week Plan That Lands Before the Meter Starts

Counting from today, there are about six weeks to the community end of life and roughly ten weeks to Azure's December 11 standard support end date. AWS and Google Cloud leave more room, but the holiday change freeze in most companies removes a large part of December. A realistic plan treats mid-December as the deadline for production cutovers.

Weeks 1 and 2 are inventory. List every PostgreSQL 14 instance, including staging, analytics replicas, and the database behind that internal tool someone set up in 2022. For each one, record the provider, size, extensions and versions, the owning team, the applications that connect to it, and the drivers and ORM versions they use. This is the same inventory discipline we recommended for the .NET 8 and 9 end of support and the Python 3.10 end of life, and many teams will find the three lists share owners.

Weeks 3 to 5 are compatibility. Add the target PostgreSQL version to CI so the full test suite runs against it, and fix what breaks: public schema grants in test setup, backup scripts, search_path in functions, MD5 roles. Then restore a recent production snapshot onto the target version and run the application's heaviest queries against it, comparing plans and timings with 14. This is where most surprises appear, and it is far cheaper to find them here than at cutover.

Weeks 6 to 8 are rehearsal. Perform the chosen upgrade path end to end on a production-sized copy, time it, write the runbook, and test the rollback. For blue/green, that means practising the switchover and confirming how the application's connection pools and drivers behave during it. Weeks 9 and 10 are the production cutovers, starting with the least critical databases and ending with the most critical, each followed by a day of close monitoring before the next.

Why This Keeps Landing on the Same Overloaded Team

The uncomfortable pattern this autumn is clustering. Python 3.10 reaches end of life on October 31, .NET 8 and 9 on November 10, and PostgreSQL 14 on November 12. In most companies, all three land on the same small platform or backend team, which is also expected to ship the product roadmap. Something gives, and it is usually the upgrade that looks least urgent. Databases look least urgent because the cloud provider keeps them running, which is exactly why they end up on extended support.

A database upgrade is also unusually well suited to a focused external team. The scope is clear, the success criteria are measurable, and the work needs experience more than product context: someone who has already debugged a blue/green switchover, rebuilt pgvector indexes after an upgrade and untangled search_path problems in expression indexes. That experience is hard to hire for a one-off project and expensive to build in-house on a deadline.

This is where Stepto's model fits. Our nearshore database engineers and DevOps team in Serbia work in European time zones with good overlap for US East Coast clients, and join your repositories, cloud accounts and team rituals rather than working behind a ticket queue. For a PostgreSQL upgrade, that means the inventory, CI changes, rehearsal and cutover are run by engineers who have done them before, while your own team stays on the roadmap.

For companies facing several end-of-life dates at once, a dedicated development team can take the whole upgrade programme: database, runtime and framework together, with one plan and one owner. The goal is not just to clear this autumn's deadlines, but to leave behind CI on current versions, written runbooks and a habit of upgrading every year or two, so the next end of life is a routine ticket rather than a project.