PostgreSQL 14 end of life: how to upgrade before November 12, 2026

What ends on November 12, 2026

The PostgreSQL project supports each major version for 5 years after its first release, then ships one final minor release and stops (versioning policy). PostgreSQL 14 came out on September 30, 2021. Its final release is November 12, 2026, which is also the date of the next scheduled minor releases (release roadmap).

Minor releases are where bug fixes, security fixes and data corruption fixes ship. Once 14 stops getting them, anything found later stays unfixed on 14. Your database keeps running.

PostgreSQL 19 reached its first release candidate on October 15, 2026 (announcement) and isn't on the supported list yet. Don't wait for it: 18 is the newest supported major and has the most years left.

Plenty of setups still run 14. About 72,000 public files on GitHub say image: postgres:14 (GitHub's code search count, November 2, 2026, approximate).

Where the version hides in your repo

To find them, run these from the repository root:

git grep -nE "postgres(ql)?:14"
git grep -nE "engine_version|POSTGRES_14"
git grep -n "postgresql-14"

An untagged image: postgres pulls whatever the newest major is on the day the container is created. Pin the major you've tested.

Managed databases set their own dates

If a cloud provider runs your database, its date is the one that counts, and it often isn't the community date. Amazon RDS for PostgreSQL, for example, keeps 14 in standard support until February 28, 2027, then charges for Extended Support until February 28, 2030 (AWS release calendar). Google Cloud SQL and the others set their own schedules too. We track these on the calendar:

• Amazon RDS for PostgreSQL
• Amazon Aurora PostgreSQL
• Azure Database for PostgreSQL
• Heroku
• PostgreSQL itself

On a managed service, use the provider's major version upgrade instead of running the tools below yourself. The testing steps still apply.

Three ways to upgrade

You can go from 14 straight to 18 without stopping at 15, 16 or 17, but read the release notes for each version in between (versioning policy). The upgrading docs describe three methods:

pg_upgrade

Install 18 next to 14, create the new cluster with initdb, then run a check first. -c checks both clusters and changes no data (pg_upgrade docs). The paths are placeholders:

pg_upgrade -c \
  -b /old/14/bin -B /new/18/bin \
  -d /old/14/data -D /new/18/data

• Stop both servers and drop -c to run it for real. Add -k for link mode: it skips copying files, but once you start the new cluster you can't go back to the old one.
• PostgreSQL 18's initdb turns data checksums on by default, and pg_upgrade needs both clusters to match. If your 14 cluster has no checksums, create the new one with checksums off; initdb has a new option for that (18 release notes).
• Install the 18 build of every extension's shared library, such as pgcrypto, before you run it. Don't run CREATE EXTENSION in the new cluster: pg_upgrade copies those definitions over.
• Upgrading to 18 keeps most planner statistics, but not ones made with CREATE STATISTICS. Afterwards, run vacuumdb -a -Z to analyze every database, as the docs recommend.

Dump and restore

The simplest and slowest path. For production, the upgrading docs recommend running pg_dumpall from the newer version, which can read servers back to 9.2. Don't just bump the image tag on a volume that holds 14 data: major versions change the data directory format, so 18 can't start on it (versioning policy). For a local Docker Compose database you can rebuild, this is enough:

docker compose exec db pg_dumpall -U postgres > dump.sql
docker compose down -v
docker compose up -d db
docker compose exec -T db psql -U postgres < dump.sql

down -v deletes the volume, so check dump.sql before you run it. Between the second and third commands, change the image to postgres:18. From 18 on, Docker's image docs say to mount the volume at /var/lib/postgresql, not /var/lib/postgresql/data (Docker image docs). Run vacuumdb -a -Z after the restore so the planner has statistics.

Logical replication

Logical replication works between major versions. Build an 18 server, let it catch up with 14, then switch your app over (upgrading docs). Set wal_level = logical on the 14 server, which needs a restart, then on 14:

CREATE PUBLICATION upgrade FOR ALL TABLES;

And on 18:

CREATE SUBSCRIPTION upgrade
  CONNECTION 'host=old-db dbname=app'
  PUBLICATION upgrade;

Know the limits first (restrictions):

• The schema doesn't replicate. Copy it first with pg_dump -s and freeze schema changes until you switch.
• Sequences don't replicate. Set them to current values on 18 right before you move writes over, or inserts will collide.
• Large objects don't replicate.
• Tables need a replica identity, the primary key by default, for UPDATE and DELETE to replicate. Without one, those statements fail on the 14 server, which is your production database (publication docs).

What to test before you switch

Point CI at 18 first. Change the service container image, run the full test suite, and fix what breaks before you touch production. Then check these:

• Extensions. List them on 14 with SELECT extname, extversion FROM pg_extension; and confirm each one is available for 18. On a managed service, check the provider's extension list for 18.
• Query plans. Run EXPLAIN (ANALYZE, BUFFERS) on your slowest and most frequent queries on both versions and compare. pg_stat_statements helps you find them.
• Connection drivers. Update your driver to a release that supports 18. PostgreSQL 18 deprecates MD5 passwords and warns when you set one (18 release notes), so move any MD5 roles to SCRAM and make sure your driver handles it.
• Permissions on new databases. From 15 on, new databases don't let every user create objects in the public schema (15 release notes). An upgrade keeps your old permissions, but a fresh 18 database in CI or a new environment won't have them, so migrations run by a non-owner role can fail.
• Backup scripts. 15 renamed pg_start_backup() and pg_stop_backup() to pg_backup_start() and pg_backup_stop().
• The Migration section of each release note from 15 to 18. That's where the project lists every change that can break existing apps.

Where Since.dev fits

Since.dev tracks end-of-life dates like this one from the publisher's schedule. For a repository you scan or connect, it finds the exact file and line that pins PostgreSQL 14, with the days left and the version to move to.

• Scan any public GitHub repo, no sign-in.
• See every PostgreSQL date on the PostgreSQL calendar.
• Your coding agent can ask check_code over MCP with the surface runtime:postgresql@14.
• On Team and up, it opens a fix pull request for supported cases, ready for review. Nothing merges or deploys.

Questions

When is PostgreSQL 14 end of life?

Its final release is November 12, 2026, five years after it came out on September 30, 2021. After that, the PostgreSQL project ships no more fixes for 14, security fixes included.

Will PostgreSQL 14 stop working after November 12, 2026?

No. The server keeps running. It just gets no more bug or security fixes, so anything found later stays open until you upgrade.

Can I upgrade straight from PostgreSQL 14 to 18?

Yes. pg_upgrade and a dump and restore both go from 14 to 18 directly. Read the release notes of 15, 16 and 17 as well, since their changes apply to you too.

Does Amazon RDS end PostgreSQL 14 on the same day?

No. RDS keeps 14 in standard support until February 28, 2027. After that it runs under paid Extended Support until February 28, 2030. Other managed services set their own dates.