On this page · 10 sections
Summary. Microsoft posted the announcement for Azure Database for PostgreSQL extended support on 24 August 2026. Enrollment had already happened. The service auto-enrolled every flexible server running PostgreSQL 11, 12 or 13 on 1 August 2026, and billing starts on 1 September 2026, eight days after the announcement went up. The meter is live in the Azure retail price catalogue at $0.0700 per vCore-hour in East US and West US 2, rising to $0.1610 in Brazil Southeast, a 130% spread across 56 regions. Central India is $0.0980. At 730 hours a month that is $51.10 per vCore in East US and $71.54 per vCore in Central India, so a 4-vCore server in Pune or Chennai costs roughly $286 a month to keep on an engine the PostgreSQL community retired in November 2025.
The price is not the interesting part. The interesting part is that two Microsoft documents, both updated in July 2026, give different dates for when PostgreSQL 14 starts costing money, and that the upgrade path Microsoft recommends as the way out is blocked by extension rules for a large share of the servers now being charged.
What changed, and when it actually changed
The Azure updates entry is tagged "Announcement" and was created at 19:15 UTC on 24 August 2026. Its text says extended support "helps you maintain secure, supported workloads while transitioning to newer PostgreSQL versions."
The extended support documentation tells a different timeline. Azure standard support for PostgreSQL 11, 12 and 13 ended on 31 July 2026. Auto-enrollment ran on 1 August 2026. A one-month grace period covered August. Billing begins 1 September 2026.
So the announcement arrived 23 days after servers were enrolled and 8 days before the first invoice. If your only signal was the Azure updates feed, you had a week to plan an upgrade that the same documentation describes as needing a validation run, a maintenance window and a non-production rehearsal.
The eligibility table, and the MySQL precedent that ran the same play ten months earlier:
| Engine and version | Community retirement | Azure standard support ends | Extended support starts | Extended support ends |
|---|---|---|---|---|
| PostgreSQL 11 | 9 November 2023 | 31 July 2026 | 1 August 2026 | 31 March 2027 |
| PostgreSQL 12 | 14 November 2024 | 31 July 2026 | 1 August 2026 | 13 November 2027 |
| PostgreSQL 13 | 13 November 2025 | 31 July 2026 | 1 August 2026 | 12 November 2028 |
| PostgreSQL 14 | 12 November 2026 | 11 December 2026 | 12 December 2026 | 11 November 2029 |
| MySQL 5.7 | 31 October 2023 | 31 July 2026 | 1 August 2026 | 31 March 2029 |
| MySQL 8.0 | 30 April 2026 | 31 December 2026 | 1 January 2027 | 31 May 2029 |
The MySQL row matters because the MySQL extended support meter has been in the retail catalogue since 1 November 2025 at the same $0.07 per vCore-hour. Postgres customers are walking a path MySQL customers finished walking in August. The Azure MySQL version support policy is also more explicit about what gets metered: "Read replicas and HA-enabled servers are billed according to the additional vCores consumed." The PostgreSQL page does not say that. If you run a high-availability pair plus two read replicas, ask your account team to confirm the vCore count in writing before September closes.
The date conflict on PostgreSQL 14
Two Microsoft pages disagree by 29 days.
The version policy page, last updated 10 July 2026, lists the Azure Standard Support End Date for PostgreSQL 14 as 12 November 2026, matching the community retirement date exactly.
The extended support page, last updated 14 July 2026, lists 11 December 2026 for the same field, with extended support starting 12 December 2026.
One of those is wrong, and the gap is a month of unmetered or metered runtime on every PostgreSQL 14 flexible server in the estate. Treat 12 November 2026 as the planning date, because it is the conservative one and it is the date the community controls. Then get the answer in writing from support, because a 4-vCore Central India server sitting in that ambiguity is about $286 either way.
There is a second contradiction in the same set of pages. The version policy page still describes the pre-extended-support world: "When the community retires a PostgreSQL version, Azure Database for PostgreSQL stops applying bug or security patches to the database engine." Extended support exists precisely to sell those patches. The page has not been reconciled with the product it now links to.
A third, smaller one sits inside a single page. The extended support enrollment section offers an "Opt-out option: You can opt out at any time by upgrading to a supported version." Four paragraphs later the FAQ asks whether you can opt out and answers: "No." Both statements describe the same reality, that upgrading is the only exit, but only one of them is honest about it. There is no opt-out. There is an upgrade.
What it costs, by region
The meter is published as "Extended Support vCore" under the product name "Azure Database for PostgSQL Extended Support", spelling included, with an effective start date of 1 March 2026 in the Azure retail prices API. Fifty-six regions carry it.
| Region | Per vCore-hour | Per vCore-month (730 h) | Premium over East US |
|---|---|---|---|
| East US, East US 2, Central US, West US 2, West US 3 | $0.0700 | $51.10 | baseline |
| UK South | $0.0875 | $63.88 | 25% |
| West India | $0.0966 | $70.52 | 38% |
| Central India, Southeast Asia | $0.0980 | $71.54 | 40% |
| West Europe | $0.1001 | $73.07 | 43% |
| South India | $0.1057 | $77.16 | 51% |
| Switzerland West | $0.1302 | $95.05 | 86% |
| Brazil Southeast | $0.1610 | $117.53 | 130% |
Two consequences fall out of that table. First, extended support is charged on top of compute and storage, so a legacy server in South India carries a 51% surcharge on the surcharge relative to the same server in Virginia. Second, the meter does not apply to servers in a stopped or failed state; the documentation restricts billing to servers in a "Succeeded (running)" state. Dev and staging copies of a PostgreSQL 12 server that nobody stops at night are the cheapest thing to fix this week.
Against AWS, Azure is cheaper and flatter. These are the current us-east-1 rates from the AWS Price List API, offer version 20260820203529, effective 1 August 2026:
| Offer | Year 1 to 2 | Year 3 | Unit |
|---|---|---|---|
| Azure Database for PostgreSQL extended support (East US) | $0.0700 | $0.0700 | vCore-hour |
| Amazon RDS extended support for PostgreSQL | $0.1000 | $0.2000 | vCPU-hour |
| Aurora Serverless v2 with PostgreSQL, extended support | $0.0850 | $0.1700 | ACU-hour |
| Azure Database for MySQL extended support (East US) | $0.0700 | $0.0700 | vCore-hour |
| Amazon RDS extended support, year-3 escalator | n/a | 2x year 1 | multiplier |
Azure sits 30% below RDS in year one and 65% below it in year three, because Azure has published no year-three escalator. That flatness is a real budgeting difference, and it is also a reason the deadline pressure feels softer than it should. We have written before about how the RDS extended support bill lands for MySQL 8.0, and the pattern holds: the fee is small enough to approve and large enough to never stop paying.
The escape hatch is blocked for the servers being billed
Microsoft's stated way to stop the charge is an in-place major version upgrade. The extended support page recommends a target: "Consider upgrading to newer versions such as PostgreSQL 15 or 16."
PostgreSQL 15 leaves Azure standard support on 11 November 2027. Recommending it in August 2026 buys 15 months.
The bigger problem is that the major version upgrade documentation, updated 6 August 2026, blocks several of those paths outright for exactly the version range now being metered.
| Extension | Blocked when | Effect on a billed PG 11, 12 or 13 server |
|---|---|---|
| orafce | Source version is PostgreSQL 11, 12 or 13 | Blocks every in-place path from the three billed versions |
| pgrouting | Target is 15; or source below 16 with target 16 or later; or target is 18 | Rules out 15, 16, 17 and 18, leaving only 14 |
| pg_hint_plan | Target version is PostgreSQL 14 | Rules out the one target pgrouting leaves |
| session_variable, anon, age | All upgrade paths | Must be dropped and re-created around the upgrade |
| pg_repack, hypopg, pg_partman | All upgrade paths, by design | Non-persistent, drop before and re-create after |
| TimescaleDB from PostgreSQL 11 | Matrix allows PostgreSQL 12 only | The only legal target is itself in extended support |
That last row is the one to sit with. A PostgreSQL 11 server running TimescaleDB has exactly one supported in-place target, PostgreSQL 12, and PostgreSQL 12 was enrolled in extended support on the same day at the same price. The upgrade does not stop the bill. It moves the deadline from 31 March 2027 to 13 November 2027 and keeps the meter running the entire time.
A server carrying both pgrouting and pg_hint_plan has no legal in-place target at all. The documented alternative is side-by-side migration with logical replication, which is a project, not a maintenance window.
Three more items from the same page that turn a one-hour change into a two-week one:
Upgrading from PostgreSQL 11 requires SCRAM authentication to be enabled first and every role password reset. That is a coordinated application change, not a database task.
Geo-replicated read replicas, including cascading replicas, must be deleted before the primary upgrades and re-created afterwards. On an HA-enabled server, Azure disables HA, upgrades, then re-enables it, and re-enabling needs spare capacity to provision a new standby.
There is no automated rollback. The documented recovery is a point-in-time restore to a moment before the upgrade, onto a new server.
Who this is and how to check in ten minutes
Run three checks before 1 September.
List every flexible server and its engine version across all subscriptions. Anything on 11, 12 or 13 is already enrolled. Anything on 14 has a date that two Microsoft pages disagree about.
For each of those servers, list installed extensions and compare against the blocked table above. orafce, pgrouting, pg_hint_plan, TimescaleDB and PostGIS are the ones that decide whether this is a maintenance window or a migration project.
Run the upgrade validation checks that the documentation describes. They evaluate readiness without changing the server version, triggering downtime or restarting anything, and they surface unsupported extensions, logical replication slots, prepared transactions and event triggers. They will not run on read replicas, and they need the server in a Ready state with connectivity to every database.
Then stop the non-production servers you do not need overnight. Stopped servers are not billed for extended support.
The real cost here is usually the extension audit, not the upgrade. Teams that budget for pg_upgrade and not for the search_path work around PostGIS, the event-trigger drop and recreate, and the SCRAM password reset are the ones that miss the window twice.
India-specific considerations
Central India at $0.0980 and South India at $0.1057 per vCore-hour sit 40% and 51% above the cheapest US regions for an identical meter. For teams that chose an Indian region for data-residency reasons under the Digital Personal Data Protection Act 2023, that premium is not optional, because moving the workload to East US to save $26 per vCore per month would move personal data out of the country.
The practical response is to shrink the vCore count that carries the surcharge rather than the rate. Consolidating three small PostgreSQL 12 servers onto one correctly sized instance before September cuts the extended support line proportionally, and it is the same work the upgrade needs anyway. Our note on choosing a PostgreSQL 14 upgrade target covers the version selection, and the Azure HorizonDB versus Flexible Server comparison covers the case where the answer is to leave Flexible Server entirely rather than upgrade in place.
What is still unknown
Microsoft has not published which of the two PostgreSQL 14 dates is authoritative. It has not documented, on the PostgreSQL page, whether read replicas and HA standbys are metered separately, though the MySQL page says they are. It has not said what happens to a server that is still on PostgreSQL 11 after 31 March 2027, when its extended support window closes and no further paid option is listed. And the retail catalogue still carries the product name "Azure Database for PostgSQL Extended Support", which is a small thing until you are writing a cost-allocation filter against it.
FAQ
How eCorpIT can help
Our database team runs PostgreSQL major version upgrades on Azure Flexible Server, including the extension audit that decides whether a server can move in place at all. We handle the SCRAM migration for PostgreSQL 11 estates, the PostGIS and TimescaleDB paths that the in-place upgrade blocks, and the logical replication cutover when side-by-side is the only option. Read more about our PostgreSQL end-of-life upgrade and migration service, or book a Postgres version audit before the September meter starts. Teams tracking this alongside wider spend should also read our cloud FinOps guide for Indian teams.
References
Last updated: 25 August 2026.
