PostgreSQL 14 Dies November 12: A CNPG Upgrade Runbook

On November 12, 2026, PostgreSQL 14 stops receiving fixes. Not deprecated, not maintenance mode — done. The last release it will ever get, 14.24, already shipped on August 13, bundled with a twelve-year-old remote-code-execution flaw that turns a backup account into a superuser. If you run tenant databases on CloudNativePG and any of them still sit on a 14.x image, you have about nine weeks to move them.

Here is the whole runbook up front: patch everything to 14.24 this week, pick one of three upgrade paths from the decision table below, run the seven-item pre-flight checklist including the new output_plugin_libraries audit, land on Postgres 17 or 18 — not 19 — and finish by November 5 so the deadline is a non-event.

In one line per path: in-place pg_upgrade for most tenant databases, online logical replication for the ones that cannot stop, offline import for dev. The rest of this post is the evidence and the details behind each of those calls.

The deadline is nine weeks out​

Three dates matter, and they all come from the same August release cycle:

Why should "no more fixes" scare you? The August release fixed CVE-2026-6471, nicknamed PostGREShell: a logical-decoding flaw present since version 9.4 that lets any account with the replication attribute — the exact attribute backup and monitoring tools routinely hold — escalate to superuser with a persistent backdoor.

A flaw of that caliber discovered on November 13 ships a fix for every supported major and nothing at all for 14. Version 14.24 is effectively the last PostgreSQL 14 release ever: the next quarterly update train lands after the EOL date, so there is no 14.25 coming to save you.

Even the managed world agrees on the schedule. Amazon's release calendar already lists November 12, 2026 as the community EOL for Postgres 14, with standard RDS support ending February 2027 before paid Extended Support pricing kicks in. CloudNativePG 1.30's own release notes carry the same line: PostgreSQL 14 support ends on November 12, 2026. Self-hosting does not buy you extra time here; it just means nobody else is going to do the upgrade for you.

Pick your upgrade path: a decision table​

CloudNativePG gives you three distinct ways to move a cluster to a new major version, and choosing wrong is the most expensive mistake in this whole project — it decides your downtime, your rollback story, and which gotchas apply. Here is the table; find your row.

The default choice for a typical tenant fleet: in-place pg_upgrade for everything that tolerates a short window, which is most web-app databases under a few hundred gigabytes. Reserve the online logical-replication path for the handful of databases whose owners will not grant you a window — it is genuinely near-zero-downtime, but every row in its "watch out" column is a cutover rehearsal you must actually perform, not read about. Use offline import for dev and staging, where simplicity beats speed and the old cluster sitting around costs nothing.

One more input to the decision: size your rehearsal, not just your production run. Whichever path you pick, the first migration of each type happens against a staging clone with production-like data, timed end to end. The number you get there — eleven minutes offline, forty seconds of cutover lag, three hours of restore — is the number you put in the maintenance notice, not a guess.

Pre-flight checklist before you touch a primary​

Every failed major upgrade I have read about skipped one of these seven steps. Do them in order; each one is cheap and each one catches a different class of outage.

1. Inventory every Cluster still on 14.x. Query your fleet for the running image tag, not your Git manifests — the two disagree more often than anyone admits. Anything pinned to a 14 image, including forgotten staging and internal tooling databases, goes on the list.
2. Patch everything to 14.24 first. This gets the PostGREShell and to_char fixes (CVE-2026-14669, a heap-buffer-overflow RCE with published proof-of-concept code) onto your fleet now, and — just as important — it surfaces the August release's one breaking behavior change on a minor upgrade, where rollback is trivial, instead of during your major upgrade.
3. Audit logical slots and their output plugins. List every replication slot and note which output plugin each one uses. The August fix introduced output_plugin_libraries, an allow-list that refuses to load any logical-decoding plugin it does not name. After patching, wal2json slots fail until wal2json is listed, third-party replicators like Spock need their plugin named alongside the in-tree pgoutput and test_decoding, and the wal2json project itself had to update its docs in early September to tell users about the new parameter. Discover this on staging, not on cutover night.
4. Run pg_upgrade --check and believe it. The check now fails when the new cluster's output_plugin_libraries does not permit the old cluster's slot plugins — that failure is the audit from step 3 expressed as a gate. Fix the allow-list, never the check.
5. Build the extension matrix. For each extension in production — PostGIS, pgvector, Timescale, anything custom — confirm a build exists for your target major in your CNPG image catalog before migration day. Extensions are the number-one reason an otherwise clean pg_upgrade aborts, and the fix is always "days earlier," never "during the window."
6. Take a fresh base backup and rehearse a restore. CNPG's backup machinery is only as good as your last tested restore. Recover to a scratch cluster and point a staging app at it; if that does not work on a calm Tuesday, it will not work during an upgrade gone sideways.
7. Rehearse the full path, including the app. Cut over a staging clone end to end: migrate, advance sequences, replay the DDL you froze during replication, reconnect the app, run smoke queries. Time it. That timing is your maintenance window.

Where to land: 17 or 18, not 19​

PostgreSQL 19 Beta 3 shipped the same day as the August minors, and general availability is expected in late September — right in the middle of your migration window. Do not let the new-release smell distract you.

Its headlines are genuinely attractive: an in-core REPACK with a nonblocking CONCURRENTLY option that retires the pg_repack extension dance, SQL/PGQ property-graph queries over existing tables, and parallel autovacuum. But a GA that is weeks old has zero bake-in time in CloudNativePG images and zero field reports from fleets like yours. No reason to let it carry your tenant primaries when two excellent supported options exist.

Land on Postgres 18 for most clusters: CloudNativePG 1.30 already defaults new clusters to the 18.4 image with Kubernetes 1.36 support, and the five-year support policy gives 18 runway into 2030.

Choose Postgres 17 for any cluster whose extension matrix from step 5 has a gap on 18 — 17 is supported into 2029, which is an eternity in which to close an extension lag. A boring upgrade that finishes beats an ambitious one that stalls on a missing PostGIS build. Either target clears the November deadline with years to spare; that is the entire point.

Work the calendar backwards from November 12​

From September 11 you have roughly nine weeks — 62 days. Here is the fleet-wide schedule; compress the early weeks, never the later ones.

• Week 1 (now): inventory and patch. List every 14.x cluster, patch the fleet to 14.24, confirm the CVE fixes are live. This week alone removes the worst risk even if everything else slips.
• Weeks 2–3: staging rehearsals. Build the extension matrix, fix output_plugin_libraries entries, run pg_upgrade --check everywhere, and time one full migration of each path type against production-like clones.
• Weeks 4–6: migrate in waves. Dev and staging first, then low-risk tenants on the in-place path. One wave per maintenance window, with the rollback plan from the decision table briefed before each window opens — not improvised during it.
• Weeks 7–8: the hard ones. Online-path migrations for the databases that could not take a window, with frozen DDL, rehearsed cutovers, and app owners on call.
• Week 9 (by November 5): stragglers and buffer. Anything still on 14 gets executive attention while there is still a week of slack. November 12 should be the day you verify zero 14.x images remain, not the day you start the last migration.

PostgreSQL 14 had a good run — five years of service since September 2021, multiranges, LZ4 toast compression, and a generation of applications that never had to think about it. It earned a planned retirement, not an incident. Nine weeks, three paths, seven checklist items: start this week and the EOL notice reads like a calendar reminder instead of a postmortem prompt.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.