PostgreSQL 14 End of Life Checklist: 14 Steps Before 12 November 2026

The short answer

PostgreSQL 14 gets its final community release on 12 November 2026. To prepare: list every 14 cluster, replica and managed instance; check each extension against a PostgreSQL 17 or 18 build; choose pg_upgrade or logical replication; rehearse with a tested backup and a rollback; and decide what covers any cluster you cannot move. Managed clouds keep 14 running for a fee after their own standard support ends.

Target PostgreSQL 18 (18.6, supported until 14 November 2030) or 17 (17.11, until 8 November 2029). PostgreSQL 19 reached release candidate 1 on 15 October 2026 and had not been released on 28 October, so it is not an upgrade target for this deadline.

Dates for PostgreSQL 14

Sources: postgresql.org versioning policy and release roadmap, the AWS RDS and Aurora PostgreSQL release calendars, Microsoft Learn and Google Cloud documentation, all checked 28 October 2026. OSSeva's PostgreSQL 14 end-of-life page and EOL tracker list the same community date.

Phase 1: Find and inspect

Step 1. List every PostgreSQL 14 server

Run SHOW server_version; on each cluster you know of, then look for the ones you do not.

pg_lsclusters                       # Debian and Ubuntu hosts
rpm -qa | grep -i postgresql        # RPM-based hosts
grep -rnE "postgres(ql)?:14" --include="Dockerfile*" --include="*.yml" --include="*.yaml" .
kubectl get pods -A -o custom-columns=NS:.metadata.namespace,POD:.metadata.name,IMAGE:.spec.containers[*].image | grep -E ":14([.-]|$)"

Count every copy: streaming standbys, read replicas, logical replication subscribers, reporting copies restored from backups, test and staging databases, and PostgreSQL bundled inside vendor software that you do not control.

Step 2. List the managed instances

aws rds describe-db-instances --query "DBInstances[?Engine=='postgres' && starts_with(EngineVersion,'14.')].[DBInstanceIdentifier,EngineVersion]"
aws rds describe-db-clusters --query "DBClusters[?Engine=='aurora-postgresql' && starts_with(EngineVersion,'14.')].[DBClusterIdentifier,EngineVersion]"
az postgres flexible-server list --query "[?starts_with(version,'14')].[name,resourceGroup]"
gcloud sql instances list --filter="databaseVersion:POSTGRES_14"

Run the AWS commands in every Region and account.

Step 3. Record the minor version and update it now

The current 14 minor is 14.24 (August 2026). On RDS, minors 14.18 and 14.19 reached end of standard support on 31 October 2026, so any instance still on them needs a minor upgrade first. AWS also states that an instance must be on the latest engine minor to receive RDS Extended Support.

Step 4. Inventory extensions in every database

SELECT extname, extversion FROM pg_extension ORDER BY extname;

Run it in each database, not just the default one. For every extension, confirm a build exists for the target major version, then read that extension's own upgrade notes. PostGIS, TimescaleDB and pg_partman each publish theirs. pg_upgrade --check reports extension libraries missing from the new installation, but it cannot tell you whether the new extension version behaves the same.

Step 5. Check clients, poolers and tooling

List application drivers and ORMs, connection poolers, backup tools, Patroni or repmgr versions and monitoring queries. Each must support the target version. PostgreSQL 18 also emits deprecation warnings when MD5 passwords are set, so list roles that still use them and plan the move to SCRAM.

Phase 2: Choose the path

Step 6. Pick the upgrade method per cluster

The PostgreSQL versioning policy allows going from 14 straight to 17 or 18 without intermediate versions. The commands, breaking changes between 14 and 18, and a test plan are in Upgrade PostgreSQL 14: pg_upgrade vs logical replication; the general method is in the PostgreSQL major version upgrade guide.

Step 7. Decide what to do with managed instances

Prices are the vendors' published rates as seen on 28 October 2026; they vary by Region and change. For worked AWS numbers at real instance sizes, see the cost of RDS Extended Support for PostgreSQL and OSSeva vs AWS RDS Extended Support. Decide per instance whether to pay, upgrade in place, or use an RDS blue/green deployment.

Phase 3: Rehearse and protect

Step 8. Take a backup and prove you can restore it

Run a full backup plus pg_dumpall --globals-only for roles and tablespaces, restore it to a scratch server, and check row counts. Confirm WAL archiving and point-in-time recovery work on the new version before you rely on them.

Step 9. Rehearse on a production-sized copy

1. Run pg_upgrade --check with the old and new binaries. It does not change data.
2. Time a full upgrade, including statistics rebuilds afterwards.
3. Run the application's test suite and compare slow queries from pg_stat_statements before and after.
4. Test failover, backups, pooler and monitoring on the new version.

Step 10. Write the rollback plan before the change window

PostgreSQL's documentation says a pg_upgrade --link run can return to the old cluster only if the new cluster was never started, by removing the .old suffix from global/pg_control. The --swap mode destructively modifies the old cluster once file transfer begins. For logical replication, reverse replication from the new cluster to the old one keeps a way back. Record which of these applies to each cluster and who decides to roll back.

Phase 4: Cut over

Step 11. Upgrade in dependency order

Non-production first, then lower-risk production, then the cluster everything depends on. Upgrade standbys by the procedure in the pg_upgrade documentation or rebuild them from the new primary.

Step 12. Handle logical replication details

If you use logical replication, freeze DDL during the move. The PostgreSQL documentation states that schema and DDL are not replicated and that sequence data is not replicated, so copy sequence values before pointing applications at the new cluster.

Step 13. Verify and clean up

Re-run the step 1 and 2 commands and expect zero 14 results. Check backups, replication lag, and application error rates for a full business cycle. Keep the old data directory or instance until the new backup chain is proven, then remove it and update the inventory.

Phase 5: Plan for what cannot move

Step 14. Choose a cover option and record it

Some clusters cannot move by 12 November: an extension with no 17 or 18 build, a vendor application certified only on 14, or a change freeze. For each, write down the owner, the target date, compensating controls and who accepted the risk.

• Managed instances: pay the cloud provider's extended support (step 7) while you upgrade.
• Self-managed servers: OSSeva provides patched PostgreSQL 14 builds after 12 November 2026: the last community minor plus backported fixes for security and data-corruption issues, as signed DEB and RPM packages, tarballs and container images that install on the same data directory. Critical CVEs are patched within 48 hours and High within 7 days (OSSeva's support SLA). Assure adds migration planning to 17 or 18 and 24/7 reactive support. Operate adds a 15-minute P1 response. OSSeva's builds are for self-managed servers, not RDS, Azure or Cloud SQL instances. See PostgreSQL end-of-life support, OSSeva for PostgreSQL and what happens to PostgreSQL security after end of life.

What changes on 12 November 2026

One-page printable checklist

Frequently asked questions

When does PostgreSQL 14 reach end of life?

12 November 2026. That is the date of the final 14.x community release, five years after the first release on 30 September 2021.

Will PostgreSQL 14 stop working on 12 November 2026?

No. It keeps running. The change is that the community stops releasing security and bug fixes for it.

Can I upgrade from PostgreSQL 14 directly to 18?

Yes. The PostgreSQL versioning policy says you can upgrade from one major version to another without upgrading to the versions in between, and it recommends reading the release notes of each.

Should I upgrade to PostgreSQL 17 or 18?

Choose 18 unless an extension you depend on has no 18 build. Community support runs to 14 November 2030 for 18 and 8 November 2029 for 17.

What happens to RDS for PostgreSQL 14 after 12 November 2026?

Standard support continues until 28 February 2027. From 1 March 2027 it is Extended Support, billed per vCPU-hour, unless you upgrade or disable enrolment, in which case RDS upgrades the instance.

How can I keep PostgreSQL 14 patched on my own servers after community end of life?

Use a third-party patched build. OSSeva supplies backported security and data-corruption fixes for PostgreSQL 14 after 12 November 2026. See PostgreSQL end-of-life support.