--- title: "PostgreSQL 14 End of Life (November 12, 2026) | Since.dev" description: "PostgreSQL 14 gets its final release on November 12, 2026. Where the version hides in your repo, three ways to upgrade, and what to test first." canonical_url: https://since.dev/guides/postgresql-14-end-of-life last_updated: 2026-11-04 --- # PostgreSQL 14 end of life: how to upgrade before November 12, 2026 PostgreSQL 14 gets its final release on November 12, 2026. After that, the community stops shipping fixes for it, security fixes included, so upgrade to PostgreSQL 18 with pg_upgrade, a dump and restore, or logical replication. Updated November 4, 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](https://www.postgresql.org/support/versioning/)). 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](https://www.postgresql.org/developer/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. From the PostgreSQL versioning policy, as of Nov 4, 2026 | Version | First release | Final release | | ------- | ------------------ | ----------------- | | 18 | September 25, 2025 | November 14, 2030 | | 17 | September 26, 2024 | November 8, 2029 | | 16 | September 14, 2023 | November 9, 2028 | | 15 | October 13, 2022 | November 11, 2027 | | 14 | September 30, 2021 | November 12, 2026 | PostgreSQL 19 reached its first release candidate on October 15, 2026 ([announcement](https://www.postgresql.org/about/news/postgresql-19-rc-1-released-3409/)) 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 Where PostgreSQL 14 is pinned | Place | Look for | Watch out for | | ------------------ | ---------------------------------------------------------------------- | -------------------------------------------------------------------------- | | docker-compose.yml | image: postgres:14, 14-alpine or 14.x | A volume that already holds 14 data. See the dump and restore steps below. | | Dockerfiles | FROM postgres:14 | Extension packages built for 14, such as postgresql-14-\* | | CI workflows | A service container with image: postgres:14 | Tests that pass on 14 say little about 18 | | Helm values | image.tag, or the chart's appVersion | The chart's own version is not the PostgreSQL version | | Terraform | engine_version (RDS, Aurora), version (Azure), POSTGRES_14 (Cloud SQL) | The provider's own end date, covered below | 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](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-release-calendar.html)). Google Cloud SQL and the others set their own schedules too. We track these on the calendar: - [Amazon RDS for PostgreSQL](https://since.dev/calendar/amazon-rds-postgresql.md) - [Amazon Aurora PostgreSQL](https://since.dev/calendar/amazon-aurora-postgresql.md) - [Azure Database for PostgreSQL](https://since.dev/calendar/azure-database-for-postgresql.md) - [Heroku](https://since.dev/calendar/heroku-postgres.md) - [PostgreSQL itself](https://since.dev/calendar/postgresql.md) 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](https://www.postgresql.org/support/versioning/)). The [upgrading docs](https://www.postgresql.org/docs/18/upgrading.html) describe three methods: Upgrade methods, from the PostgreSQL 18 docs | Method | Downtime | Good fit | | ------------------- | ------------------------------------ | ---------------------------------- | | pg_upgrade | Minutes, especially in link mode | Servers you run yourself | | Dump and restore | As long as the dump and restore take | Small databases, local dev and CI | | Logical replication | Several seconds at switchover | Large databases that can't go down | ### 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](https://www.postgresql.org/docs/18/pgupgrade.html)). 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](https://www.postgresql.org/docs/18/release-18.html)). - 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](https://www.postgresql.org/docs/18/upgrading.html) 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](https://www.postgresql.org/support/versioning/)). 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](https://github.com/docker-library/docs/blob/master/postgres/content.md)). 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](https://www.postgresql.org/docs/18/upgrading.html)). 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](https://www.postgresql.org/docs/18/logical-replication-restrictions.html)): - 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](https://www.postgresql.org/docs/18/logical-replication-publication.html)). ## 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](https://www.postgresql.org/docs/18/release-18.html)), 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](https://www.postgresql.org/docs/release/15.0/)). 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](https://since.dev/scan.md), no sign-in. - See every PostgreSQL date on the [PostgreSQL calendar](https://since.dev/calendar/postgresql.md). - Your coding agent can ask `check_code` over [MCP](https://since.dev/docs.md#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. ## Put your code on continuous management. Scan a public repository now, or give your agent one line. ### See how out of date your code is. [Scan a repository](https://since.dev/scan.md). Any public GitHub repository. No sign-in. ### Tell your agent what changed since it was trained. `claude mcp add --transport http since https://api.since.dev/mcp` --- Every page on this site as Markdown: https://since.dev/sitemap.md. For agents: https://since.dev/llms.txt.