PostgreSQL 14 dies 12 November 2026: the Extended Support bill on AWS, Azure and Google Cloud

Summary. PostgreSQL 14 stops receiving fixes on 12 November 2026, five years and six weeks after its 30 September 2021 release, and the PostgreSQL versioning policy leaves no appeal. What follows is not one deadline but three. Amazon RDS ends standard support for PostgreSQL 14 on 28 February 2027 and starts Extended Support billing on 1 March 2027. Azure Database for PostgreSQL flexible server ends standard support on 11 December 2026 and starts paid Extended Support on 12 December 2026, eleven weeks before AWS starts billing. Cloud SQL enrols PostgreSQL 14 instances in extended support on 1 February 2027. AWS's own worked example prices Extended Support at $0.100 per vCPU-hour for the first two years in US East (Ohio), doubling to $0.200 in year three, and Reserved Instance discounts do not apply to it. On a 16-vCPU instance that arithmetic is $1,168 a month of pure penalty, before the standby you are also billed for. The engineering question is smaller than the calendar suggests: PostgreSQL 15 dies on 11 November 2027, so the only sensible targets are 17 (8 November 2029) or 18 (14 November 2030).

What actually changes on 12 November 2026

Nothing breaks. That is the trap. A PostgreSQL 14 cluster keeps serving traffic on 13 November exactly as it did the day before. What stops is the supply of fixes.

The scale of what you give up is visible in the last release. PostgreSQL 14.23, shipped 14 May 2026 alongside 18.4, 17.10, 16.14 and 15.18, closed 11 security vulnerabilities and more than 60 bugs. Four of those CVEs carried a CVSS v3.1 base score of 8.8: CVE-2026-6473, an integer wraparound that lets an input provider undersize a server allocation and write out of bounds; CVE-2026-6475, symlink following in pg_basebackup and pg_rewind; CVE-2026-6477, a libpq large-object path that lets a server superuser overwrite pg_dump or psql stack memory; and CVE-2026-6637, a stack buffer overflow in the refint module that allows an unprivileged database user to execute arbitrary code as the operating system user running the database. Every one of those affected versions 14 through 18. That is the normal shape of a PostgreSQL minor release, and after 12 November 2026 the 14 column of that table is empty.

"Eleven CVEs is the largest single-release security batch I can remember, and three of them are CVSS 8.8 with practical exploitation paths," wrote Christophe Pettus of PostgreSQL Experts (PGX) in his analysis of the May 2026 release. His administrative note at the end of that post is the one that matters here: "PostgreSQL 14 reaches end of life on November 12, 2026 ... If you are on 14 in production, you have one more minor release after this one before you are running unsupported PostgreSQL. Plan accordingly."

There is also a quieter CVE worth reading twice. CVE-2026-6478 is a covert timing channel in the comparison of MD5-hashed passwords. The PostgreSQL project notes it does not affect scram-sha-256 passwords, the default in all supported releases, but that current databases may still hold MD5 hashes inherited from upgrades off PostgreSQL 13 or earlier. Pettus gives the one-line check:

            SELECT rolname FROM pg_authid WHERE rolpassword LIKE 'md5%';
          

If that returns rows on a PostgreSQL 14 cluster, you have two pieces of work, not one: the upgrade, and a password-hash migration that has been waiting since whenever you came off 13.

Do not upgrade to 15

The single most expensive mistake available here is upgrading 14 to 15 because the version number is adjacent. The PostgreSQL versioning policy publishes the final release date for every major version, and the table settles the argument:

A 14-to-15 upgrade buys twelve months and costs the same engineering effort as a 14-to-18 upgrade. PostgreSQL supports jumping straight from one major version to another without the intervening ones, and the project's own guidance is to read the release notes of every version you skip rather than to step through them. Going to 17 or 18 is the same migration with three or four times the runway.

Between 17 and 18 the tiebreaker is upgrade mechanics, not features. PostgreSQL 18 keeps planner statistics through a major-version upgrade, so an upgraded cluster reaches expected performance without waiting for ANALYZE to finish, and its pg_upgrade adds a --swap flag that swaps upgrade directories instead of copying, cloning or linking files, plus parallel checks driven by --jobs. Because pg_upgrade runs from the target version's binaries, a 14-to-18 jump gets all of that; a 14-to-17 jump does not.

The same release introduced an asynchronous I/O subsystem that, per the project's announcement as reported by ADMIN Magazine, "demonstrated up to 3x performance improvements when reading from storage" and "lets PostgreSQL issue multiple I/O requests concurrently instead of waiting for each to finish in sequence". It is selectable through the new io_method setting, with worker, io_uring and sync options.

18 also carries three gotchas that belong in your test plan rather than your production window. Clusters initialised by PostgreSQL 18 initdb have page checksums enabled by default, so pg_upgrade from a non-checksum cluster requires creating the new cluster with --no-data-checksums. Full text search now uses the cluster's default collation provider instead of always using libc, which may require reindexing every full text search and pg_trgm index after pg_upgrade. And md5 password authentication is deprecated and will be removed in a future release, so plan the move to SCRAM as part of the same change window.

The three Extended Support clocks

Every managed provider sells the same product with a different calendar and a different billing trigger. Read your own row before you plan anything.

Three details in that table cost real money. Azure's clock starts on 12 December 2026, eleven weeks before AWS's, so a mixed estate does not have one deadline. Cloud SQL's date is derived: Google's extended support policy says an instance enters extended support three months after community EOL, and the Cloud SQL version table then publishes 1 February 2027 for PostgreSQL 14 with deprecation on 1 February 2030. And on Cloud SQL, deprecation is not a warning: when a major version is deprecated, Cloud SQL upgrades every instance on it to the default major version automatically, as part of regular maintenance.

Azure's version of automatic is more aggressive still. Microsoft's Extended Support documentation records that servers running unsupported versions were automatically enrolled on 1 July 2026 with billing beginning 1 August 2026, and answers "Can I continue using my PostgreSQL instance without Extended Support?" with a flat no. The escape hatch is upgrading, and only upgrading. Two provisions are worth knowing: billing applies only to servers in a running (Succeeded) state, so a stopped server does not accrue extended support charges, and if regional capacity constraints prevent an upgrade, Azure says the server is temporarily excluded from extended support billing until an upgrade path is offered.

What Extended Support actually costs on RDS

AWS prices RDS Extended Support per vCPU per hour, varying by Region, PostgreSQL version, and the number of calendar years since standard support expired. It does not publish a rate for PostgreSQL 14, and anyone quoting you one is guessing. What AWS does publish, on the RDS for PostgreSQL pricing page, is a worked example: an instance on RDS for PostgreSQL 12 in US East (Ohio) is charged $0.100 per vCPU-hour between 1 March 2025 and 28 February 2027, then $0.200 per vCPU-hour from 1 March 2027. A second example puts a PostgreSQL 11 db.r5.large in US East (N. Virginia) at $0.200 per hour, which AWS spells out as 2 vCPUs times $0.100 per vCPU-hour.

Use that published rate as the arithmetic base and the shape of the bill becomes obvious. At $0.100 per vCPU-hour and 730 hours in a month:

Those figures are the surcharge alone. Instance, storage, backup and data transfer charges continue unchanged underneath them. Four rules from AWS's own FAQ decide whether your real bill matches this table or beats it:

Reserved Instance discounts do not apply. AWS states plainly that Extended Support charges are independent of instance charges, so a three-year RI on a PostgreSQL 14 instance discounts the compute and nothing else.

Every instance in a Multi-AZ deployment is charged. With one standby you pay Extended Support on the primary and the standby; with two readable standbys you pay on all three. Read replicas on an end-of-standard-support major version are charged too. A production topology of one primary, one standby and two read replicas multiplies the table above by four.

You must be on the latest minor version to receive Extended Support at all. That is not a billing footnote, it is an availability condition: a cluster parked on 14.19 does not get the Extended Support patches it is being enrolled for.

Snapshots are free, restores are not. AWS does not charge Extended Support on DB snapshots, but restoring a snapshot to a new instance running an end-of-standard-support version starts the charges on that instance. Disaster-recovery runbooks that restore PostgreSQL 14 snapshots after 28 February 2027 quietly create billable instances.

A 14-week upgrade plan that fits before the deadline

Working back from 12 November 2026, a team starting in August has roughly fourteen weeks of calendar. This is the sequence that survives contact with production.

Weeks 1-2, inventory and extension audit. Enumerate every PostgreSQL 14 cluster, its minor version, its vCPU count, its Multi-AZ topology and its replica count, because those four numbers are the entire Extended Support exposure. Then list every non-core extension. Azure's documentation is explicit that the platform upgrades the database engine but non-core extensions such as pgvector and timescaledb require manual updates via ALTER EXTENSION ... UPDATE or recreation after the upgrade. Extension availability on the target major version is the most common reason an upgrade date slips.

Weeks 3-5, target selection and a restored-copy rehearsal. Pick 17 or 18 using the runway table, then rehearse pg_upgrade on a restored copy of production, not on a synthetic dataset. If the target is 18, this is where --no-data-checksums and the full text search reindex either appear or ambush you later.

Weeks 6-9, application validation. PostgreSQL 18 makes virtual generated columns the default for generated columns, adds uuidv7(), introduces a new wire protocol version 3.2 while libpq continues to default to 3.0, and changes CREATE SUBSCRIPTION to use parallel streaming by default. Driver, pooler and proxy behaviour is where a major-version upgrade actually fails, so validate the client side with the same rigour as the server side.

Weeks 10-12, upgrade-blocker cleanup and a dry run. Microsoft's guidance for reducing downtime is worth reusing on any provider: identify and fix upgrade blockers such as extensions, roles and replication slots ahead of the upgrade, pause background jobs and long-running sessions, temporarily scale up compute to speed up pg_upgrade, clear bloat with VACUUM or REINDEX, and run ANALYZE afterwards. On a target of 18 the last step matters less, because planner statistics now survive the upgrade.

Weeks 13-14, cutover and verification. Take the window, upgrade, then confirm you are on the latest minor of the new major version. That last check is what keeps you eligible for support at all.

For clusters that cannot take a maintenance window, logical replication into a new cluster on the target version and a short read-only cutover is the standard alternative. It costs more setup and gives you a rollback that a pg_upgrade does not. For a deeper comparison of the target-version trade-offs, see our analysis of the PostgreSQL 14 end-of-life upgrade target decision, and for the tuning work that follows an 18 upgrade, the PostgreSQL 18 asynchronous I/O and UUIDv7 migration guide.

Extended support is sometimes the right answer

Paying the surcharge is a defensible decision in two situations, and pretending otherwise leads teams to rush an upgrade they cannot test.

The first is a hard dependency you do not control: an extension with no build for the target version, a vendor application certified only against PostgreSQL 14, or a compliance freeze over the change window. Here Extended Support is what AWS and Microsoft both describe it as, a bridge. Microsoft's documentation says to treat it as a temporary bridge rather than a long-term solution, and notes that servers in Extended Support can raise support cases for security-related issues only, with feature requests, performance tuning and general bug fixes excluded.

The second is small instances. At the published PostgreSQL 12 example rate, a 2-vCPU instance costs $146 a month in year one and two. If you run three of those and an engineer-week of upgrade work costs more than the surcharge through 2028, the arithmetic genuinely favours waiting, provided someone owns the date.

What is not defensible is drifting into year three. The rate doubles on 1 March 2029 for RDS PostgreSQL 14, and Cloud SQL will upgrade the instance for you at deprecation on 1 February 2030 whether or not you have tested it. Enrolment is automatic on all three providers, which means the default outcome of doing nothing is a bill, not an outage. That is precisely why it goes unnoticed.

India-specific considerations

For teams running production databases in ap-south-1, Central India or asia-south1, three points change the shape of this work.

Region availability governs the rehearsal, not just the cutover. Azure's Extended Support FAQ concedes that regional capacity constraints can prevent an upgrade, and commits to excluding such servers from Extended Support billing temporarily. If your upgrade slips for capacity reasons, that exclusion is worth claiming rather than absorbing.

Personal data crossing a region during a rehearsal is a Digital Personal Data Protection Act 2023 question, not only a cloud question. A restored copy of production used for upgrade testing is production data. Keep the rehearsal cluster in the same region, apply the same access controls, and delete it on a schedule. Where an upgrade rehearsal needs a masked dataset instead, that is a data-architecture decision worth making deliberately - see our work on data residency and DPDP cloud architecture.

Extended Support pricing varies by Region, and AWS's published examples are US East. Any Indian-region estimate built from the $0.100 per vCPU-hour figure is an approximation to be replaced with a real quote from the AWS Pricing Calculator, which AWS points to for exactly this purpose. The broader cost picture is covered in our guide to cutting cloud spend for Indian teams and in the analysis of whether AWS Database Savings Plans are worth it.

How to decide this week

Three numbers decide the whole thing, and you can collect them in an afternoon. Total vCPUs on PostgreSQL 14, including every standby and read replica. The number of non-core extensions with no confirmed build on your target version. And the date your change-freeze calendar next allows a database window before November.

If the extension list is clean and a window exists, upgrade to 18 and take the four-year runway. If the extension list is not clean, upgrade to 17 and revisit. If neither is true, budget Extended Support deliberately, put the year-three rate-doubling date in the same ticket, and treat the surcharge as a financed upgrade rather than an accident. The real cost here is almost never the upgrade; it is the twelve months of surcharge nobody put in a budget line.

FAQ

How eCorpIT can help

eCorpIT is a Gurugram-based technology consulting organisation, founded in 2021, with CMMI Level 5, MSME and ISO 27001:2022 certifications and partnerships with AWS, Microsoft and Google. Our senior-led database and platform engineers run PostgreSQL major-version upgrades end to end: extension and driver compatibility audits, target-version selection against the published support runway, pg_upgrade and logical-replication rehearsals on restored production copies, and cutover with rollback planned in advance. We design upgrade and rehearsal environments aligned with Digital Personal Data Protection Act 2023 requirements, keeping production copies in-region with controlled access. If you are carrying PostgreSQL 14 into 2027 and want the Extended Support exposure quantified before it becomes a budget line, talk to us and we will start with the vCPU and extension inventory.

References

1. PostgreSQL: Versioning Policy - PostgreSQL Global Development Group, five-year support policy and the final release date for every major version.

1. PostgreSQL 18.4, 17.10, 16.14, 15.18, and 14.23 Released with security fixes - oss-sec archive of the 14 May 2026 announcement: PostgreSQL 14 EOL notice, 11 CVEs and over 60 bug fixes.

1. PostgreSQL 18 release notes - asynchronous I/O, pg_upgrade --swap and parallel --jobs checks, planner statistics retention, page checksums, full text search collation change and md5 deprecation.

1. Release calendars for Amazon RDS for PostgreSQL - RDS end of standard support, Extended Support year 1 and year 3 pricing start dates for PostgreSQL 14.

1. Amazon RDS for PostgreSQL Pricing - Extended Support priced per vCPU-hour, the PostgreSQL 12 and 11 worked examples, Reserved Instance, Multi-AZ, read replica and snapshot rules.

1. Azure Database for PostgreSQL extended support - eligible versions table, automatic enrolment, billing start dates and the extension upgrade guidance.

1. Extended support for Cloud SQL - automatic enrolment, three-year duration, per vCPU-hour pricing model and opt-out by upgrade.

1. Database versions and version policies, Cloud SQL for PostgreSQL - extended support start date of 1 February 2027 and deprecation date of 1 February 2030 for PostgreSQL 14.

1. CVE-2026-6473: PostgreSQL server undersizes allocations, via integer wraparound - CVSS v3.1 base score 8.8, affecting versions 14 to 18.

1. CVE-2026-6637: PostgreSQL refint allows stack buffer overflow and SQL injection - CVSS v3.1 base score 8.8, arbitrary code execution as the database operating system user.

1. CVE-2026-6478: PostgreSQL discloses MD5-hashed passwords via covert timing channel - MD5 hashes inherited from upgrades off PostgreSQL 13 or earlier.

1. CVE-2026-6475: PostgreSQL pg_basebackup and pg_rewind can overwrite unrelated files - symlink following, CVSS v3.1 base score 8.8.

1. PostgreSQL 18 Released - ADMIN Magazine, quoting the project announcement on up to 3x read performance from the new I/O subsystem.

1. Eleven CVEs Walk Into a Release - Christophe Pettus, PostgreSQL Experts (PGX), 14 May 2026, severity analysis and the MD5 hash check query.

Last updated 7 August 2026.