PostgreSQL 14 hits end of life on 12 November 2026: pick 17, 18, or wait for 19

Summary. PostgreSQL 14 receives its final minor release on 12 November 2026 and is then unsupported, exactly 5 years and 6 weeks after its first release on 30 September 2021. After that date the PostgreSQL Global Development Group ships no security fixes, no bug fixes and no minor updates for 14, whatever is disclosed. The decision is not whether to move. It is what to land on, and the support runway per target is lopsided: 15 expires 11 November 2027, 16 on 9 November 2028, 17 on 8 November 2029, and 18 on 14 November 2030. Version 19 is in beta, with Beta 2 released 16 July 2026, and the project has it planned for September 2026, with the beta announcement itself saying "around September/October 2026". On Amazon RDS the money starts moving earlier than the community date: RDS end of standard support for PostgreSQL 14 is 28 February 2027, and Extended Support billing begins 1 March 2027 at a rate AWS illustrates as $0.100 per vCPU-hour for year 1 and 2, doubling to $0.200 per vCPU-hour in year 3. One more date matters for planning: the next community minor release is 13 August 2026, and the one after that is 12 November 2026, which is the same day 14 dies.

"The efforts of the global open source community shape every PostgreSQL release and help deliver features that meet users where their data resides," said Jonathan Katz, a member of the PostgreSQL core team, in the PostgreSQL 18 release announcement. The practical version of that for a team on 14 is simpler: five years of upstream work is now sitting between you and the current release, and skipping intervening versions is explicitly supported.

What "end of life" actually removes

The PostgreSQL Global Development Group supports a major version for five years after its initial release. After that, a final minor version is released and the software is unsupported. There is no grace period, no partial coverage and no security-only tail from the community.

The project also states its own position on minor upgrades plainly: performing minor upgrades is considered less risky than continuing to run an old minor version, and users should always run the current minor release for their major version. Once 14 is end of life, there is no current minor release to run. That is the whole risk, and it does not depend on whether a specific CVE has landed yet.

That table is the entire argument against 15. A 14-to-15 upgrade costs the same outage, the same testing and the same rollback planning as a 14-to-18 upgrade, and buys twelve months instead of forty-eight. Teams pick 15 because it feels like the smallest step. Major-version upgrades in PostgreSQL do not price that way: the data directory is incompatible across any major version boundary, so the cost is a step function, not a gradient. You can upgrade from one major version to another without upgrading through the intervening versions, though the project recommends reading the release notes of every intervening major version before you do.

The four candidate targets, honestly compared

Why 18 is the default answer for most teams

PostgreSQL 18 introduced an asynchronous I/O subsystem that lets the database issue multiple I/O requests concurrently instead of waiting for each to finish in sequence. It covers sequential scans, bitmap heap scans and vacuum, and the project's own release announcement reports benchmarking gains of up to 3x in certain scenarios when reading from storage. The io_method setting toggles between worker and io_uring, or sync to keep the pre-18 behaviour, which is a useful escape hatch during a cautious rollout.

The upgrade-specific improvements matter more than the headline number for anyone jumping four versions. Before 18, planner statistics did not carry over on a major-version upgrade, so a busy system could sit in degraded query performance until ANALYZE finished. PostgreSQL 18 keeps planner statistics through the upgrade. pg_upgrade in 18 is also faster when a database contains many tables and sequences, runs its checks in parallel according to --jobs, and adds a --swap flag that swaps upgrade directories instead of copying, cloning or linking files.

Read that again if you are on a database with a short maintenance window. The version you upgrade to supplies the pg_upgrade binary, so a 14-to-18 jump gets 18's faster upgrade path and its statistics carryover. A 14-to-16 jump does not.

Developer-facing additions in 18 that change schema decisions: virtual generated columns computed at query time, now the default for generated columns; uuidv7() for timestamp-ordered random UUIDs with better indexing and read behaviour; OLD and NEW values both available in the RETURNING clause for INSERT, UPDATE, DELETE and MERGE; and temporal constraints over ranges via WITHOUT OVERLAPS on PRIMARY KEY and UNIQUE, and PERIOD on FOREIGN KEY.

The three things in 18 that will bite you during the upgrade

Page checksums are enabled by default for databases initialised with PostgreSQL 18's initdb. Upgrading from a cluster that does not have checksums enabled requires creating the new 18 cluster with --no-data-checksums when using pg_upgrade. Check SHOW data_checksums; on your 14 cluster before you plan anything.

Full text search in 18 uses the cluster's default collation provider instead of always using libc. That may require reindexing all full-text-search and pg_trgm indexes after pg_upgrade runs. On a large table that reindex is the real maintenance window, not the upgrade itself.

md5 password authentication is deprecated in 18 and will be removed in a future release. If any application user still authenticates with md5, move it to SCRAM before the upgrade rather than during it.

When 17 is the right call

Pick 17 if your extension set or managed platform does not yet have first-class 18 support, if you have an application that depends on libc-based full-text-search collation behaviour and cannot afford the reindex right now, or if your organisation has a hard policy against running the newest major version. Three years of runway to 8 November 2029 is a defensible answer. It is a deliberate trade, not a default.

When waiting for 19 is defensible, and when it is not

PostgreSQL 19 is planned for September 2026, and the Beta 2 announcement dates the final release "around September/October 2026". Beta 2 shipped on 16 July 2026 with fixes covering the new FOR PORTION OF temporal table syntax, the new SQL/PGQ property graph feature, REPACK worker cleanup on a FATAL exit, virtual generated column tuple deformation, and pg_createsubscriber accepting duplicate publication names.

Waiting is defensible if your 14 cluster is small, your change window is easy to schedule, and you can realistically be on 19 before 12 November 2026. That is a narrow gap: a September or October general availability leaves four to eight weeks to test and cut over, and the project publishes no guarantee on the exact date.

Waiting is not defensible if you are on a managed platform. Managed providers add a version after the community release, not on the day of it. Amazon RDS publishes its own currency timeline: major versions land within 30 days of the community release of the first minor of the new major version, which is <major>.1, not <major>.0. That is why the RDS calendar records PostgreSQL 18's community release date as 13 November 2025 while postgresql.org records 18's first release as 25 September 2025. The two dates are not in conflict, but planning against the wrong one costs you about seven weeks.

The managed-service clock runs on a different calendar

This is the part teams miss. Community end of life and provider end of standard support are separate dates with separate consequences, and on Amazon RDS the second one has a price tag.

AWS publishes the mechanics rather than a single number: Extended Support is priced per vCPU per hour and varies by region, PostgreSQL version and the number of calendar years since standard support expired. Its own worked example uses PostgreSQL 12 in US East (Ohio) at $0.100 per vCPU-hour from 1 March 2025 to 28 February 2027, stepping to $0.200 per vCPU-hour from 1 March 2027. A second published example prices a db.r5.large running PostgreSQL 11 in US East (N. Virginia) at $0.200 per hour, shown as 2 vCPUs multiplied by $0.100 per vCPU-hour.

Apply that arithmetic to your own fleet before it applies itself. At the $0.100 per vCPU-hour rate AWS publishes in those examples, an 8 vCPU instance running continuously costs 8 x $0.100 x 8,760 hours, which is $7,008 for a year of Extended Support on top of everything else you already pay for that instance. In rupee terms for an Indian team budgeting in INR, that is a line item large enough to fund the migration work several times over.

Four details in the AWS terms decide whether your estimate is right:

Extended Support charges apply to standby instances in Multi-AZ deployments. With one standby you pay on both; with two readable standbys you pay on all three. Read replicas running a version past end of standard support are charged too.

Reserved Instance discounts do not apply to Extended Support charges, because those charges are independent of instance charges.

You must be on the latest engine minor version to receive Extended Support at all. Falling behind on minors does not save money here, it removes the safety net.

You can refuse the charge entirely by preventing RDS from creating or restoring an instance past the end of standard support date, using open-source-rds-extended-support-disabled for the --engine-lifecycle-support option in the AWS CLI, or LifeCycleSupport in the RDS API. That converts a surprise bill into a hard failure, which is usually what you want in a non-production account.

One more scheduling trap sits in the RDS minor-version calendar. Minor versions reach end of standard support before their major version does. RDS lists 14.19 and 14.18 at September 2026 while major version 14 runs to 28 February 2027. Being on a supported major version is not the same as being on a supported minor.

A migration plan that fits the remaining weeks

Fourteen weeks remain between 6 August 2026 and 12 November 2026. That is enough for a careful upgrade and not enough for a leisurely one.

Inventory first. Record the exact major and minor version of every cluster, including the ones nobody owns: analytics replicas, staging, the CI database, the ancient reporting instance. Query SELECT version(); rather than trusting your infrastructure code.

Pick one target for the whole estate. Running 16 in one place and 18 in another doubles your extension matrix and your runbook count for no benefit. If a single cluster genuinely cannot move to 18, move it to 17 and document why.

Audit extensions before anything else. Extension availability, not core PostgreSQL, is what usually blocks a jump. Check every extension against the target version, and check the version your managed provider or container image actually ships. Teams running the Supabase stack should read this alongside the self-hosted Supabase breaking changes runbook, because the extension version pinning change interacts directly with a major-version upgrade.

Rehearse with pg_upgrade --check on a restored copy of production, not on a synthetic dataset. Run it, read every warning, then run the real upgrade against the same copy and time it. That number is your maintenance window, plus the reindex time if you are landing on 18 and use full-text search or pg_trgm.

Decide the cutover method by downtime tolerance. pg_upgrade with --link or 18's --swap is fastest and hardest to reverse. A dump and reload is slowest and simplest. Logical replication into a new cluster costs the most setup and buys the shortest cutover, which is usually right for anything customer-facing.

Keep the old data directory until an application test suite has passed against the new cluster, not until the database starts. Those are different milestones and only the second one means anything.

Teams running Postgres under an operator will find the sequencing differs again, and the Postgres on Kubernetes operator comparison covers how each one handles major-version upgrades. If the outcome of this exercise is a move off self-managed entirely, the trade-offs are laid out in Neon versus Supabase for a serverless Postgres backend, and the features that arrive with 19 are covered in the PostgreSQL 19 production guide. For the wider platform picture these decisions sit inside, see the web platform developer guide for 2026.

India-specific considerations

For Indian teams the deadline arrives with a second cost that does not show up on an AWS invoice. Under the Digital Personal Data Protection Act 2023, running a database that can no longer receive security patches is difficult to defend as a reasonable security safeguard for personal data. The community position is unambiguous after 12 November 2026: no fixes, of any severity, ever again for 14.

Extended Support on a managed platform changes that calculus, because a paid patch stream is still a patch stream. It does not change it for a self-managed cluster on an EC2 instance or in a colocation rack, where end of life means exactly what it says. Teams building the surrounding controls will find the groundwork in the DPDP Act engineering playbook for Indian startups.

Budget for the migration in the current financial year rather than the next one. The Extended Support meter starts 1 March 2027, three days into FY 2027-28, which is exactly the kind of boundary that turns a planned engineering cost into an unplanned run-rate cost.

The upgrade is rarely the hard part. Finding every cluster is.

FAQ

How eCorpIT can help

eCorpIT plans and executes PostgreSQL major-version upgrades end to end: full cluster inventory, extension compatibility audit against the target version, a rehearsed pg_upgrade on restored production data to size the real maintenance window, and a cutover method chosen against your actual downtime tolerance. Our senior engineering teams work across self-managed Postgres, managed services and Kubernetes operators, and we design deployments aligned with DPDP requirements. eCorpIT is CMMI Level 5, MSME Certified and ISO 27001:2022 certified. If you have clusters on PostgreSQL 14 and fourteen weeks left, talk to us.

References

1. PostgreSQL Versioning Policy, PostgreSQL Global Development Group

1. PostgreSQL Roadmap, PostgreSQL Global Development Group

1. PostgreSQL 19 Beta 2 Released, 16 July 2026

1. PostgreSQL 18 Released, 25 September 2025

1. PostgreSQL 18 release notes

1. PostgreSQL 19 release notes

1. pg_upgrade documentation, PostgreSQL

1. Upgrading a PostgreSQL cluster, PostgreSQL documentation

1. Release calendars for Amazon RDS for PostgreSQL, AWS documentation

1. Amazon RDS Extended Support charges, AWS documentation

1. Amazon RDS Extended Support overview, AWS documentation

1. Amazon RDS for PostgreSQL pricing, AWS

1. PostgreSQL release notes index

Last updated: 6 August 2026.