PostgreSQL 14 ends support and forces a production migration plan

The version 14 received its last security update this week. A migration roadmap detailed by Stormatics outlines the three decisions that determine whether migration becomes a problem or a routine.

The end of life of version 14

PostgreSQL 14 received, this Thursday, November 12, 2026, its last maintenance update, according to a post by Umair Shahid published on November 11, 2026, on Planet PostgreSQL, signed by Stormatics. From now on, no security flaw or bug found in version 14 receives a fix from the community. The database keeps running normally, but every vulnerability discovered from this date on remains open for anyone who keeps operating that version in production.

Anyone on version 14, or even on 15 (which loses support on November 11, 2027), has little time to decide the next step. Shahid sums up the problem in three decisions: which version to migrate to, which method to use, and how to carry out the traffic cutover without an incident. That is the roadmap worth unpacking, along with the risks the original text only mentions in passing.

Decision 1: where to migrate to

Each PostgreSQL major version receives five years of community support. The windows reported by the source are these:

Shahid's argument is straightforward: the effort of a major migration (checking extensions, testing the application, planning the cutover) is roughly the same no matter the destination chosen. Migrating from 14 to 15 or 16 buys one or two years of extra life for the same work; migrating straight to 18 buys four. In practice, jumping to the latest supported version tends to be the most rational decision, as long as every extension in use already has a build available for it.

Decision 2: which upgrade method

There are three paths to cross a major version, and each one defines how long the application stays offline.

• Dump and restore: simplest to reason about, but downtime grows along with the size of the database. For multi-terabyte databases, the source rules this option out.
• pg_upgrade with the --link flag: the community's official in-place upgrade tool. The flag creates hard links instead of copying the data files, so the time of the upgrade step does not depend on the stored volume. At one Stormatics client, a 100 GB production database took less than 10 minutes of downtime for that specific step.
• Blue-green upgrade: the option with the lowest downtime. The current cluster (blue) keeps serving production while a new cluster on the target version (green) is built alongside it, receiving every change in real time via logical replication. The cutover becomes a write pause of a few seconds, and existing connections reconnect to the new cluster.

Two specific pg_upgrade precautions deserve extra attention from the DBA. Statistics are not copied in the process, so running ANALYZE before releasing traffic is mandatory, under penalty of the optimizer choosing bad execution plans right in the first hour. The old data directory, in turn, must be treated as unusable as soon as the new cluster comes up; anyone who wants a rollback route needs to take a filesystem snapshot before starting, because pg_upgrade itself does not offer that safety net.

Blue-green upgrade does not work for every cluster. Large objects, tables without a primary key, and schema changes during the migration can prevent a near-zero-downtime cutover, and these constraints need to be mapped before promising anyone a short deadline.

A blue-green upgrade is the method we use wherever a cluster qualifies.

Umair Shahid, Stormatics

When the cluster does not qualify, pg_upgrade --link becomes plan B, with downtime measured in minutes rather than seconds.

Decision 3: how to carry out the cutover

The source describes the sequence used by Stormatics in production upgrades, and it works as a minimum checklist for any team that will handle this cutover internally:

1. Review: check the database, extensions, replication, connected pipelines, and connection configuration; every risk found needs to be resolved before moving forward.
2. Plan: write a step-by-step runbook with a rollback plan, and agree on the cutover window with whoever owns the application.
3. Prepare: build the green cluster on the target version and keep it in sync with production via logical replication.
4. Test: validate data, sequences, and the application's main queries, and rehearse the cutover wherever a test environment exists.
5. Switch over: move traffic on a live call with the application team, confirming the system's health right afterward.
6. Support: keep the blue cluster available as a rollback and monitor the green one closely.

Two technical details escape anyone who only skims the announcement. Sequences are not replicated by logical replication, so their values need to be adjusted manually on the green cluster before the cutover, under risk of a primary-key collision on the very first write. And the spike in reconnections at the moment of the cutover can overload a connection pool, so it is worth confirming beforehand that the application reconnects on its own and that the pooler can handle the burst.

After the cutover: validation and the safety window

A short validation closes out the process, according to the source. Confirm the version running, check for invalid indexes by querying pg_index (the query should return zero rows), compare the installed extension versions against what's available, and update anything that is behind. Logs deserve close monitoring during the first hours of real traffic, because that is when bad execution plans or unexpected locks show up.

Stormatics keeps the blue cluster available for 5 days after the cutover, with replication running in reverse (from green back to blue). This allows pointing the application back to the old cluster without losing any write made after the cutover, should something go wrong after traffic is already live on the new version.

Managed services follow the same logic

Amazon RDS, Aurora, Cloud SQL, Azure Database, and Supabase each have their own upgrade path, but the three decisions still apply: target version, method, and discipline in the cutover. In the specific case of AWS, according to Stormatics, RDS's and Aurora's Blue/Green Deployments use the same logical replication for major upgrades; it's worth checking directly in AWS's official documentation whether the specific cluster qualifies for the cutover and what rollback guarantees exist before relying on that path.

What changes for whoever runs a database in production

Stormatics cites a concrete case: production clusters of a banking software provider migrated from version 13 to 17 with near-zero downtime. That is the kind of result that only holds up when the review in step 1 is taken seriously, and not treated as a formality before 'just running the script.'

For anyone who decides to handle this migration with their own team, instead of hiring Stormatics' service (offered starting at $9,990 per cluster, according to the source), the roadmap above is reproducible at no additional cost beyond engineering time. The difference between a smooth cutover and a production incident is not in the tool chosen, but in how much of the review step was done before any command ran: extensions without a build for the target version, tables without a primary key, and invalid indexes left behind tend to be among the reasons an upgrade that seemed ready wasn't.

It is worth noting what the material does not address: it does not discuss the behavior of read replicas during the logical replication window, nor the effect of triggers and extensions that depend on internal PostgreSQL APIs throughout the version jump. Whoever administers this kind of cluster does well to test exactly these points before setting the cutover date.