PostgreSQL 15 end of life (11 November 2027): the upgrade path to 18 or 19

Summary. PostgreSQL 15 gets its final community release on 11 November 2027, five years after 15.0 shipped on 13 October 2022; after that there are no fixes, security fixes included. Amazon RDS and Aurora end standard support on 29 February 2028 and bill RDS Extended Support from 1 March 2028 to 28 February 2031. AWS charges $0.100 per vCPU-hour in US East for every PostgreSQL version now in Extended Support, doubling in year three, but has not yet listed a rate for 15. Cloud SQL enrols 15 instances in extended support on 1 February 2028 at $0.07 per vCPU-hour in Iowa and upgrades leftovers from 1 February 2031. Azure ends standard support on 11 November 2027 and has not yet scheduled extended support for 15. The target is PostgreSQL 18, supported to 14 November 2030, or PostgreSQL 19, at release candidate 1 with general availability planned for 19 November 2026. Use pg_upgrade when minutes of downtime are acceptable and logical replication when they are not, minding its gaps: no DDL, no large objects and, from a 15 source, no sequences. Our view: take 18 if you move before mid-2027, and 19 later in 2027 once your provider and your extensions support it.

About this article. This is for teams running PostgreSQL 15 on Amazon RDS, Aurora, Azure, Cloud SQL or their own servers. On 7 November 2026 we checked every date, price and behaviour against postgresql.org and the AWS, Microsoft and Google Cloud documentation, pricing pages and price catalogues. Providers revise calendars and prices, so re-check before you book a change window. This is not legal or financial advice; the DPDP Act reference is to the text published in the Gazette of India on 11 August 2023, and no vendor paid for inclusion. Researched with AI assistance and reviewed by our editorial team.

Python 3.11, common in the same estates, loses security support in October 2027; see our Python 3.11 end of life runbook.

What ends on 11 November 2027

The PostgreSQL Global Development Group supports each major version for five years, then ships one final minor release. PostgreSQL 14 gets its final release on 12 November 2026, the next scheduled update date, which also brings a new 15 minor. The project's table on 7 November 2026:

PostgreSQL 19 is later than usual. The release team chose to fold the fixes from the 12 November update release into 19, so RC2 is due that day and GA is planned for 19 November unless a problem forces a delay. RC1 was still current on 7 November. The policy points to an end of life around November 2031; the project has not published it.

End of life does not stop a running server; it stops the fixes. You can skip intervening major versions, but the project asks you to read every intervening release note first. From 15 to 18 that means 16, 17 and 18; to 19, one more.

Managed service dates: RDS, Aurora, Azure and Cloud SQL

The provider calendars on 7 November 2026:

That hints at 19's arrival. If 19 ships on 19 November, Cloud SQL's 90 days run to about 17 February 2027. AWS counts from 19.1; if that ships on 11 February 2027, RDS follows by about 13 March 2027 and Aurora by about October 2027. That is our arithmetic, not an announcement. Microsoft publishes no commitment, though it offered 18 on the community release day.

Amazon RDS and Aurora

RDS moves 15 into Extended Support on 1 March 2028, with year-three pricing from 1 March 2030 and an end on 28 February 2031. Aurora uses the same dates and names 15.10 as its long-term support minor for 15.

Two details matter before 2028. Minors expire before majors: RDS supports 15.19 only until September 2027, so keep patching 15 while you plan. And the RDS pricing FAQ says an instance must be on the latest minor to receive Extended Support.

Azure Database for PostgreSQL flexible server

Microsoft lists 11 November 2027 as the end of Azure standard support for 15, matching the community date. Extended support adds up to three years with automatic enrolment and no exit except upgrading, and its table covers 11 to 14 only. For 14, Azure now lists 31 January 2027, 80 days after the community date; a similar buffer for 15 is possible but unannounced. Plan against 11 November.

Its FAQ adds a point that applies everywhere: the engine upgrade leaves noncore extensions such as pgvector and TimescaleDB for you to update.

Cloud SQL for PostgreSQL

Cloud SQL puts PostgreSQL 15 into extended support on 1 February 2028 and deprecates it on 1 February 2031. On deprecation, Cloud SQL upgrades remaining instances to the default major version during maintenance, after at least 12 months' notice. Extended support covers critical and high-severity CVEs, keeps SLA coverage and still allows new 15 instances.

What extended support costs

Rates come from AWS's price list files (29 October 2026), Azure's retail prices API and pricing page, and Google's pricing page.

AWS says the rate depends on Region, version and year; its examples and every provisioned PostgreSQL rate it lists today (10 to 13) are $0.100 and $0.200 in US East, so use $0.100 for 15 until AWS lists it. Microsoft now states that year three costs twice the year one and two rate. All of these come on top of instance, storage and backup costs.

Choosing the target: PostgreSQL 18 or 19

Skip 16 and 17: they end in November 2028 and 2029, one or two years before 18, for the same testing effort.

Frameworks set floors too. The draft Django 6.2 release notes drop PostgreSQL 15 and require 16 or later, with 6.2 expected in April 2027. A Django application on 15 must move the database before taking that LTS; see our Django 6.2 LTS guide.

pg_upgrade or logical replication

You can cross major versions by dump and restore, pg_upgrade, or logical replication into a new cluster. Dump and restore is simple and slow; above tens of gigabytes the choice is between the other two. The table draws on the PostgreSQL and AWS documentation.

pg_upgrade from 15: four things to know

1. Checksums must match. PostgreSQL 18 changed initdb to enable data checksums by default, and pg_upgrade requires matching checksum settings. If your 15 cluster has checksums off, initialise the new cluster with --no-data-checksums, or enable them on the old cluster offline with pg_checksums first.

1. Statistics now survive. From 18, pg_upgrade carries planner statistics across, though not extended statistics. The documentation then has you run vacuumdb twice, as in the runbook below.

1. Logical slots do not survive from 15. PostgreSQL 17 taught pg_upgrade to migrate logical replication slots and subscriptions, but only when the old cluster is 17 or later; slots on older clusters are silently ignored. From 15, Debezium and other CDC consumers lose their slots and need a planned resync.

1. Use the fast modes. --link hard-links data files, --clone uses copy-on-write where the file system supports it, 17 added --copy-file-range, and 18 added --swap, which moves directories instead of copying files. 18 also runs its pre-upgrade checks in parallel with --jobs.

Logical replication: near-zero downtime, with gaps

Logical replication streams row changes from the 15 publisher into an 18 or 19 subscriber, and you cut over when lag is near zero. AWS's Blue/Green limitations page is the most candid list of what goes wrong, and most of it applies elsewhere. DDL or a GRANT on the source degrades replication to the new (green) side, and you must recreate the deployment. Large objects are not replicated. Materialised views are not refreshed. The apply process is single-threaded, so a write-heavy source can outrun it. pg_partman must be disabled on the source and pg_cron kept off on the target, and point-in-time recovery history does not carry over after switchover.

PostgreSQL 19 replicates sequence values, but only from a 19 or later publisher, so from 15 you sync sequences yourself at cutover.

What breaks between 15 and 18 or 19

The release notes for 17, 18 and 19 list these incompatibilities, among others. Read 16's notes as well.

Arriving in 17:

• Functions run with a safe search_path during maintenance such as REINDEX and materialised view refresh, so expression indexes and materialised views on functions that rely on an unqualified search_path can fail.

• old_snapshot_threshold and the adminpack extension are removed.

Arriving in 18:

• initdb enables data checksums by default (see above).

• MD5 passwords are deprecated and setting one now warns. Move roles to SCRAM.

• VACUUM and ANALYZE process inheritance children by default; COPY FROM no longer treats \. as end-of-file in CSV files; unlogged partitioned tables are disallowed; AFTER triggers run as the role active when the event was queued.

• Full text search uses the cluster's default collation provider. On clusters that default to ICU or the builtin provider, reindex full text search and pg_trgm indexes after pg_upgrade.

Arriving in 19:

• RADIUS authentication is removed.

• standard_conforming_strings is forced on; dumps made by older pg_dump with it off will not load properly, so dump with 19's tools.

• pg_upgrade refuses clusters with btree_gist indexes on inet or cidr columns, and clusters whose database, role or tablespace names contain carriage returns or line feeds.

• JIT is off by default; analytics-heavy sites must turn it back on.

• Successful MD5 logins now produce a warning.

Extension compatibility

Extensions are where managed upgrades fail. AWS says most are not upgraded with the RDS engine, and Microsoft says the same of noncore extensions. Three rules cover most cases:

1. The target must offer your extension. Compare pg_extension on 15 with your provider's list for 18 or 19; a missing library fails the pg_upgrade checks.

1. Some extensions block specific paths. Azure lists them by source and target. A 15 to 18 move is blocked by pgrouting, pg_diskann, azure_ai, azure_storage, azure_local_ai and pg_failover_slots; session_variable, anon and age block every path; pg_repack, hypopg and pg_partman must be dropped and recreated. TimescaleDB is allowed from 15 to 18. Run Azure's pre-upgrade validation for your exact path.

1. Update after the engine. Run ALTER EXTENSION ... UPDATE for each extension once the new engine is up, and re-test anything with its own on-disk structures, such as vector indexes. Our Postgres vector search guide covers pgvector and its relatives.

Worked example: the cost of staying on 15

Take one database with an 8-vCPU primary, an 8-vCPU high-availability standby and an 8-vCPU read replica, left on 15 past each cut-off, at 730 hours a month:

• Amazon RDS, US East (Ohio), Multi-AZ with one standby plus a replica: 24 vCPUs × $0.100 × 730 = $1,752 a month from 1 March 2028, or $21,024 a year, if 15 gets today's rate; $3,504 a month from 1 March 2030.

• Cloud SQL, Iowa, HA primary plus a replica: 8 HA vCPUs × $0.14 × 730 = $817.60, plus 8 vCPUs × $0.07 × 730 = $408.80, for $1,226.40 a month from 1 February 2028, replicas being billed at the standalone rate; $2,452.80 in year three.

• Azure flexible server, East US, primary only: 8 vCores × $0.07 × 730 = $408.80 a month, or $572.32 in Central India at $0.098, doubling in year three. Microsoft does not document how HA standbys and replicas are metered, so ask your account team.

These surcharges recur monthly until you upgrade, and double in year three on all three clouds.

India, data residency and compliance

Indian regions cost more. RDS Extended Support in Mumbai is $0.114 per vCPU-hour, 14% above Ohio, so the RDS example becomes 24 × $0.114 × 730 = $1,997.28 a month. Azure Central India is 40% above East US. Teams that keep personal data in India by policy or contract cannot move region to save, so cut vCPUs instead: consolidate small 15 instances before the cut-off. An engine without community fixes is also hard to square with the reasonable security safeguards duty in section 8(5) of the Digital Personal Data Protection Act 2023, and with GDPR Article 32. Our DPDP Act engineering playbook covers the wider controls.

The upgrade runbook

1. Inventory every 15 cluster: provider, region, vCPUs, replicas, HA, extensions, logical slots and cut-off date.

1. Pick 18 or 19 per cluster and record its end-of-life date.

1. Patch 15 to the latest minor to stay in support while you plan.

1. Run the checks below and fix tables without primary keys, MD5 roles, search_path-dependent functions and blocked extensions.

1. Rehearse on a restored copy with production-sized data, and time it.

1. Choose the method: in-place pg_upgrade in a maintenance window, or logical replication with a schema freeze.

1. After cutover: update extensions, rebuild statistics, reindex full text search and pg_trgm indexes where needed, and recreate CDC slots.

1. Decommission 15, including snapshots that would restore onto an end-of-life engine.

The managed commands follow the AWS, Azure and Google Cloud upgrade documentation.

            # Pre-flight checks on the PostgreSQL 15 cluster
psql -c "SHOW data_checksums;"
psql -c "SELECT extname, extversion FROM pg_extension ORDER BY 1;"
psql -c "SELECT slot_name, slot_type, plugin FROM pg_replication_slots;"
psql -c "SELECT rolname FROM pg_authid WHERE rolpassword LIKE 'md5%';"   # superuser only; managed services restrict pg_authid

# Self-managed (example paths): dry run, then a link-mode upgrade from 15 to 18
pg_upgrade -b /usr/lib/postgresql/15/bin -B /usr/lib/postgresql/18/bin \
  -d /var/lib/postgresql/15/main -D /var/lib/postgresql/18/main --check --jobs 4
pg_upgrade -b /usr/lib/postgresql/15/bin -B /usr/lib/postgresql/18/bin \
  -d /var/lib/postgresql/15/main -D /var/lib/postgresql/18/main --link --jobs 4
vacuumdb --all --analyze-in-stages --missing-stats-only --jobs 4
vacuumdb --all --analyze-only --jobs 4

# Managed services: list targets and run prechecks, then upgrade in place
aws rds describe-db-engine-versions --engine postgres --engine-version 15.19 \
  --query "DBEngineVersions[].ValidUpgradeTarget[?IsMajorVersionUpgrade].EngineVersion"
aws rds modify-db-instance --db-instance-identifier mydb --engine-version 18.6 \
  --allow-major-version-upgrade --apply-immediately
az postgres flexible-server upgrade --name mydb --resource-group my-rg --version 18 --validate-only
az postgres flexible-server upgrade --name mydb --resource-group my-rg --version 18
gcloud sql instances pre-check-major-version-upgrade mydb --target-database-version=POSTGRES_18
gcloud sql instances patch mydb --database-version=POSTGRES_18
          

How eCorpIT can help

eCorpIT is a Gurugram-based technology organisation, founded in 2021, assessed at CMMI Level 5 and MSME certified, with senior-led engineering teams working across AWS, Microsoft and Google platforms. Our PostgreSQL major version upgrade service covers inventory, extension audits, rehearsals and cutovers on RDS, Aurora, Azure, Cloud SQL and self-managed clusters. Talk to us at /contact-us/.

Last updated: 7 November 2026.

References

1. Versioning policy — PostgreSQL Global Development Group

1. Release calendars for Amazon RDS for PostgreSQL — Amazon Web Services

1. Release calendars for Aurora PostgreSQL — Amazon Web Services

1. Amazon RDS for PostgreSQL pricing, including RDS Extended Support and FAQs — Amazon Web Services

1. AWS Price List, Amazon RDS offer file for US East (Ohio), published 29 October 2026 — Amazon Web Services

1. Cloud SQL for PostgreSQL database versions and version policies — Google Cloud

1. Cloud SQL pricing, extended support pricing — Google Cloud

1. Azure Database for PostgreSQL flexible server version policy — Microsoft Learn

1. Azure Database for PostgreSQL extended support — Microsoft Learn

1. PostgreSQL 19 RC 1 Released, 15 October 2026 — PostgreSQL Global Development Group

1. Roadmap, upcoming minor releases — PostgreSQL Global Development Group

1. Upgrading a PostgreSQL cluster (PostgreSQL 18 documentation, section 18.6) — PostgreSQL Global Development Group

1. Extended support for Cloud SQL for PostgreSQL — Google Cloud

1. AWS Price List, Amazon RDS offer file for Asia Pacific (Mumbai), published 29 October 2026 — Amazon Web Services

1. Azure Retail Prices API, Azure Database for Postgres Extended Support meters — Microsoft

1. Azure Database for PostgreSQL flexible server pricing, Extended Support — Microsoft Azure

1. Django 6.2 release notes (under development, expected April 2027) — Django Software Foundation

1. Logical replication restrictions (PostgreSQL 18 documentation, section 29.8) — PostgreSQL Global Development Group

1. pg_upgrade (PostgreSQL 18 documentation) — PostgreSQL Global Development Group

1. Limitations and considerations for Amazon RDS blue/green deployments — Amazon Web Services

1. Release notes for PostgreSQL 18 — PostgreSQL Global Development Group

1. Release notes for PostgreSQL 17 — PostgreSQL Global Development Group

1. Logical replication upgrade (PostgreSQL 18 documentation, section 29.13) — PostgreSQL Global Development Group

1. Replicating sequences (PostgreSQL 19 documentation, section 29.7) — PostgreSQL Global Development Group

1. Release notes for PostgreSQL 19 (draft as of 9 October 2026) — PostgreSQL Global Development Group

1. Choosing a major version for an RDS for PostgreSQL upgrade — Amazon Web Services

1. Major version upgrades in Azure Database for PostgreSQL — Microsoft Learn

1. The Digital Personal Data Protection Act, 2023 (Gazette of India, 11 August 2023) — Ministry of Electronics and Information Technology

1. Regulation (EU) 2016/679 (General Data Protection Regulation), Article 32 — EUR-Lex

1. az postgres flexible-server upgrade, Azure CLI reference — Microsoft Learn

1. Upgrade the database major version in place, Cloud SQL for PostgreSQL — Google Cloud