PostgreSQL 14 reaches end of life on 12 November 2026 - inventory, target version and upgrade plan for self-managed and managed databases

#Why now

PostgreSQL supports each major version for five years. Version 14's final minor release is due in November 2026 (12 November). After that, the community publishes no more fixes for 14, including security fixes.

Managed services set their own policies. Some move to paid extended support, some auto-upgrade, some require you to upgrade by a deadline. For example, Aiven says it will automatically upgrade services still on 14 where possible, and STACKIT requires moving to 15 or newer. Check your provider's announcement.

#1. Find every v14

SELECT version();
SHOW server_version_num;   -- 14xxxx

Across clouds:

# AWS RDS
aws rds describe-db-instances --query "DBInstances[?Engine=='postgres' && starts_with(EngineVersion,'14')].[DBInstanceIdentifier,EngineVersion]" --output table
# Azure flexible server
az postgres flexible-server list --query "[?version=='14'].{name:name, rg:resourceGroup}" -o table

Don't forget logical replicas, reporting copies and containers (postgres:14 images in Compose and Helm charts).

#2. Choose the target

Skipping versions is fine: pg_upgrade and logical replication both go straight from 14 to 17 or 18. Read the release notes' "Migration" sections for every version you skip (15, 16, 17, 18).

Changes that commonly matter coming from 14:

• PostgreSQL 15 removed CREATE permission on the public schema for all users by default in new databases. Applications that create objects in public with a non-owner role break in new databases.
• Extensions must exist in the target version (PostGIS, pg_partman, pg_cron, TimescaleDB and so on). Check each one's supported versions.
• Some configuration parameters were renamed or removed across these versions. Diff your postgresql.conf against the target's defaults.

#3. Pick the method

Step-by-step pg_upgrade: PostgreSQL major version upgrade with pg_upgrade.

#4. Rehearse

1. Restore a recent backup to a test server on 14.
2. Upgrade it with the method you chose; time it.
3. Run ANALYZE (or vacuumdb --all --analyze-in-stages) - statistics aren't carried over by pg_upgrade.
4. Run the application's test suite and the top 20 queries by total time from pg_stat_statements; compare plans and timings.
5. Fix what breaks, then schedule production.

#5. After upgrading

• Update extensions: ALTER EXTENSION <name> UPDATE;
• Re-run ANALYZE.
• Re-create replicas on the new version.
• Update monitoring for any changed catalog views.
• Remove the old cluster once backups on the new version are verified.

#Checklist

• All v14 instances found, including replicas and containers
• Provider's v14 policy and deadline known
• Target version chosen; release notes for skipped versions read
• Extensions available for the target
• Upgrade rehearsed on a restored copy; time measured
• Post-upgrade ANALYZE, extension updates and replica rebuilds done

#Sources

• Belgian CCB: PostgreSQL patches and v14 EOL date
• WZ-IT: PostgreSQL 14 end of life on 12 November 2026
• Aiven changelog: PostgreSQL 14 EOL