Key details

  1. Azure standard support for PostgreSQL 11, 12 and 13 ended July 31, 2026.
  2. Eligible servers were automatically enrolled in Extended Support on August 1.
  3. The free grace period ends August 31 and billing starts September 1, 2026.
  4. Extended Support is billed separately by vCore-hour for running eligible servers.
  5. Customers cannot opt out while continuing to run an unsupported PostgreSQL version; upgrading to a supported major version stops the charge.
  6. Stopped, failed or deleted servers do not accrue Extended Support charges for those periods.
  7. Extended Support supplies security fixes, critical fixes and technical support but not new features or performance enhancements.
  8. Current Extended Support end dates are March 31, 2027 for PostgreSQL 11, November 13, 2027 for PostgreSQL 12 and November 12, 2028 for PostgreSQL 13.

What builders should take away

  1. Inventory every Azure PostgreSQL Flexible Server and flag versions 11, 12 and 13 before September billing lands.
  2. Estimate the new cost from provisioned/running vCores, including the consequences of high-availability topology, rather than treating Extended Support as a flat account fee.
  3. Prioritize upgrades for idle, low-risk and non-production databases where compatibility testing can be completed quickly.
  4. Test major upgrades against extensions, replication, roles, configuration parameters and application SQL in a non-production environment first.
  5. After an engine upgrade, separately update non-core PostgreSQL extensions where required.
  6. Use Extended Support as migration runway, not as a reason to postpone version planning indefinitely.

What changed

Azure Database for PostgreSQL Flexible Server versions 11, 12 and 13 reached the service’s Extended Support phase on August 1, 2026 after Azure standard support ended July 31. Microsoft provided those versions a one-month no-charge grace period. That grace period ends August 31, and Extended Support billing begins September 1. Enrollment is automatic for eligible unsupported versions. Microsoft says customers cannot continue running an unsupported version without Extended Support; the way to stop the charge is to complete a major-version upgrade to a currently supported PostgreSQL version. Extended Support is billed separately on a vCore-hour basis while an eligible server is running.

Why it matters

A database version that appeared to keep running normally in August becomes a new infrastructure cost in September. That makes engine age a FinOps issue as well as a maintenance issue. Teams with many vCores, HA replicas or forgotten non-production servers should inventory version 11–13 instances now, because the cost continues for as long as the server remains on an unsupported version and in a running state. The alternative is an in-place major upgrade, which itself needs extension, SQL and application compatibility testing.

Azure enrolled the old versions automatically

PostgreSQL 11, 12 and 13 entered Azure Extended Support on August 1 after their Azure standard-support window ended July 31. There is no separate opt-in switch. Microsoft says an eligible Flexible Server running an unsupported version is automatically covered, and customers cannot choose to keep the server running outside Extended Support.

The free month ends September 1

Microsoft gave versions 11–13 a one-month grace period through August 31. From September 1, Extended Support is a separate vCore-hour charge for servers in the Succeeded/running state. A stopped, failed or deleted server does not accrue that Extended Support charge for that period; billing resumes if it returns to a running unsupported version.

Paid support is a bridge, not a feature track

Extended Support includes security patches, critical bug fixes and access to technical support under the customer’s existing support plan. It does not include new features, performance enhancements, general bug fixes, performance tuning help or minor-version upgrade support. Microsoft explicitly recommends treating it as temporary migration time.

The escape hatch is an engine upgrade

To stop Extended Support charges, the server must be successfully upgraded to a PostgreSQL major version that Azure currently supports. Microsoft warns that major upgrades can expose incompatible extensions, deprecated parameters or SQL behavior changes. Non-core extensions such as pgvector or TimescaleDB are not automatically upgraded with the engine and may need separate work.

The support runway varies by version

Microsoft currently lists Extended Support ending March 31, 2027 for PostgreSQL 11, November 13, 2027 for PostgreSQL 12, and November 12, 2028 for PostgreSQL 13. Those dates create a hard outer boundary even for teams willing to pay the legacy-support premium.

What to watch next

  • The actual Extended Support line item on September invoices across regions and SKUs.
  • Any temporary billing exclusions Microsoft applies where regional capacity prevents a supported-version upgrade.
  • Whether Microsoft changes upgrade tooling or supported target versions as the Extended Support end dates approach.
  • Extension compatibility issues that become common during 11–13 upgrades.

Still unclear

  • The Azure pricing page renders region/currency-specific values dynamically, so the exact vCore-hour rate varies with purchasing context and should be checked in the customer’s own pricing view.
  • Major-version upgrade effort depends heavily on application behavior, installed extensions and regional capacity; the existence of an in-place upgrade path does not make every migration low-risk.

Sources

Direct reading behind this dossier.

2 sources

Discussion

Discussion is reader-contributed. Comments are not part of the BTN dossier or its editorial evidence.

0 visible comments

Join the discussion

Keep comments useful and relevant. Reader contributions may be moderated and are not BTN editorial evidence.

Sign in to comment