Three things land on the same day this week. On November 12, 2026 the PostgreSQL Global Development Group ships its quarterly minor release across every supported branch — 18.6, 17.11, 16.15 and 15.19 — and with it 14.24, the final release of PostgreSQL 14. The same day, PostgreSQL 19 RC 2 is published; general availability is scheduled for November 19. See the release roadmap and the RC 1 announcement.

Most teams will treat November 12 as a routine patching window. For anyone still on PostgreSQL 14, it is the last security fix they will ever receive. That is the story worth clearing your Thursday for.

The November 12 release slate

• 18.6 — current branch, 14 months of minor releases behind it
• 17.11 — supported through November 2029
• 16.15 — supported through November 2028
• 15.19 — supported through November 2027
• 14.24 — final release, end of life
• 19 RC 2 — same day, ahead of GA on November 19

Minor releases are binary swaps: stop the server, install the packages, restart. The community’s versioning policy is blunt about the risk calculus — it considers running an old minor version more dangerous than performing the upgrade. If you have not patched since August, this is the week.

What “final release” actually means

The versioning policy is a five-year clock from initial release. PostgreSQL 14 shipped on September 30, 2021, so 14.24 is the closing entry: after November 12 there are no bug fixes, no corruption fixes and no CVE patches for that branch. A vulnerability announced in December will be fixed in 15 through 18 and simply documented as unfixed in 14.

Two consequences beyond the obvious:

• Vendor support statements stop meaning what they used to. If an application vendor certifies “PostgreSQL 14,” ask in writing what happens after November 12. Plenty of vendors will keep saying 14 is fine because their test matrix has not moved since 2023. Get that in writing before an auditor asks.
• Tooling drifts forward too. Dasha, the open-source fleet dashboard we cover below, already requires PostgreSQL 14 or newer at the floor, and the gap widens each quarter.

Choosing a landing version

Upgrades do not have to pass through intermediate majors — the project explicitly supports 14 straight to 18 — so the decision is about runway, not sequence.

• 15 — supported to November 2027. Roughly twelve months of patching left. Do not move here.
• 16 — November 2028. Fine, but you are buying two years.
• 17 — November 2029. The common target for teams leaving 14 this quarter.
• 18 — November 2030, and six minor releases of field mileage. This is the low-risk default.
• 19 — GA November 19, first minor release February 11, 2027. Attractive features, but a .0 branch for a migration you only want to do once. We tracked the RC 1 slip when it moved GA to November 19.

My recommendation for a 14 cluster that must move in November: land on 18. If you can absorb a quarter of extra calendar time, test 19 RC 2 in CI now and plan the jump for the February-to-May 2027 window, after the first minor release has shaken out.

Pre-flight checks that catch most failed upgrades

Run these against a restored copy, not the live cluster.

-- 1. Every installed extension, every database
SELECT current_database() AS db, extname, extversion
FROM pg_extension;

-- 2. Things pg_upgrade will refuse or quietly change
SELECT count(*) AS prepared_xacts FROM pg_prepared_xacts;   -- must be 0
SELECT slot_name, slot_type, active FROM pg_replication_slots;

Then the real check — the one that validates binaries, libraries, locales and link mode without touching a single row:

pg_upgrade --check \
  -b /usr/lib/postgresql/14/bin \
  -B /usr/lib/postgresql/18/bin \
  -d /var/lib/postgresql/14/main \
  -D /var/lib/postgresql/18/main

Two failure modes it surfaces that bite people: an extension whose shared library is not installed for the target version — you need the package built for 18, not 14 — and collation or encoding differences against the old cluster’s initdb settings. Both are cheap to fix in advance and expensive to discover at 02:00.

Three more items that do not migrate the way people assume:

• Prepared transactions block the upgrade outright. Resolve any two-phase-commit residue left by a pooler or client.
• Unlogged table contents are not carried across. Definitions are, rows are not. If a cache table is load-bearing, it needs to be refillable on demand.
• Planner statistics do not migrate. pg_upgrade generates an analyze script; run it before you drop traffic back on, or day-one plans will be built from nothing.

Community news: Dasha 1.10 and the EDB–Altinity deal

Released today, Dasha 1.10 is the release that makes the dashboard worth another look if you run Patroni. It discovers clusters straight from etcd v3 or Consul by reading the DCS (never writing), matches standby clusters by PostgreSQL system identifier so a standby behind a VIP is found, and adds an Activity & Waits page sampled from pg_stat_activity every 1–10 seconds without any extension.

The feature I would actually use during an upgrade cycle is the replication slot invalidation forecast: it measures the WAL rate over a 30-second to 5-minute window and shows, per slot, the retained WAL, the remaining max_slot_wal_keep_size reserve, and the time until the slot is lost. Slot invalidation is exactly what happens when you rebuild a replica and forget one consumer. Dasha is GPLv3, installs no agent, and needs only a read-only role with pg_monitor; monitoring clusters must be 14 or newer.

On the vendor side, EDB acquired Altinity on November 5, folding the second-largest independent ClickHouse contributor into its Postgres AI platform. The roadmap is unglamorous but sensible: one Apache Iceberg catalog and consistent access controls across both engines, with integrated enterprise ClickHouse capabilities planned for Q4 2026. Altinity Stable Builds and the Kubernetes operator stay Apache 2.0. If you already bridge Postgres and ClickHouse, we covered the extension-level pattern in pg_clickhouse 0.11.

Houston: where this bites locally

The 14 clusters I see in this city are rarely greenfield. They sit behind energy trading and well-operations applications, claims processing at mid-size providers, and logistics software at the Ship Channel — often on a vendor-certified VM image nobody has rebuilt since 2022. That is precisely where a database EOL becomes a procurement problem: the app team cannot upgrade until the vendor signs off, and the vendor will not sign off until a customer asks loudly.

This week’s checklist

1. Inventory. Run SHOW server_version; against every cluster you own, including the one nobody mentions in standups.
2. Patch what you keep. Apply 18.6, 17.11, 16.15 or 15.19 to every cluster not being migrated. Free risk reduction, single restart.
3. Open the 14 ticket now. Pick a target (18 by default), restore a copy, run pg_upgrade --check, and record the wall-clock time of a full rehearsal on production-sized data.
4. Test 19 RC 2 in CI, but keep it out of production until after GA on November 19 — and preferably until the February 11, 2027 minor release.

If your team is staring at a 14 cluster and a December deadline, Postgres 14 to 18 upgrade planning is the kind of work we do — rehearsed cutover, extension audit, rollback path included.