PostgreSQL 14 reaches end of support, leaving holdout servers without security patches

PostgreSQL 14 has reached the end of its supported life. According to a post on dev.to, the PostgreSQL Global Development Group lists November 12, 2026 as the final release date for the 14 series, and once that release ships, the upstream project stops providing security patches and bug fixes for every 14.x version.

The same post warns managed-service users to check their provider's timeline separately: maintenance schedules, supported upgrade paths and extended support terms differ between services, and those dates can affect both patching and compliance requirements.

Step one: find every instance and give it an owner

The recommended starting point is an inventory that covers cloud database listings, deployment manifests and self-managed hosts across production, staging, QA and disaster recovery environments. Replicas that sit idle until a failover are flagged as the instances most likely to be missed.

The version check itself is a single query from any application connection or SQL client: SHOW server_version;.

For each 14 instance, the dev.to post advises recording the environment, the owning team and a primary engineering contact, every connected application — including scheduled jobs and BI or reporting tools that query the database outside normal traffic hours — and the available maintenance windows. Where no owner is obvious, someone should be assigned to map dependencies before any change is scheduled.

Choose a target version the stack can actually support

Next, confirm which PostgreSQL major versions your hosting platform supports and how long each will continue to receive upstream fixes, then verify compatibility with the extensions, drivers and backup tools you depend on. The example given is PostGIS: the required extension version has to exist on the target platform before a maintenance window gets booked.

Self-managed deployments have two main paths, pg_upgrade and dump-and-restore. Anyone planning to use pg_upgrade should run pg_upgrade --check during rehearsal to catch the problems the tool can detect in advance. On managed services, follow the provider's documented procedure and confirm whether a direct jump from 14 to your chosen version is supported.

Rehearse, and set the rollback trigger before cutover

Rehearsal should use a representative copy of production data: time the upgrade, exercise the application's critical read and write paths, and run background jobs that fire only occasionally. The post notes that a successful login proves little beyond basic connectivity, and suggests running a nightly reporting job separately to confirm it still has its permissions and extensions.

It also recommends restoring a backup in a test environment, timing the recovery, and comparing that number against your recovery time objective.

Two decisions belong before cutover rather than during it. The first is when to roll back, defined as an objective trigger such as an application error rate above an agreed threshold or an upgrade that overruns the maintenance window. The second is how to handle post-cutover writes: if traffic is redirected back to the old PostgreSQL 14 instance after the upgraded database has accepted writes, those transactions will be missing from the old instance unless a way exists to reconcile them.

What to aim for this week

The concrete goal is that by the end of the week, every remaining PostgreSQL 14 instance has an owner, a target version to validate and a scheduled rehearsal date. If there is time for only one action today, the post says to verify the server version behind your primary production connection and confirm who owns the upgrade.

Why it matters

A database that no longer receives security fixes turns every future vulnerability in the 14.x codebase into a permanent, unpatched exposure, and a database is usually the last component a team can swap out quickly. The deadline itself is no surprise — it comes from the project's published versioning policy — so the residual risk is operational: unowned instances, extensions that do not exist on the target version, upgrades that have never been timed against a realistic data set, and rollback decisions improvised mid-incident. The work the dev.to post outlines is deliberately mundane, because the alternative is discovering each of those gaps during an outage.