PostgreSQL 14 on Azure: from 1 February 2027 every vCore costs extra

What Extended Support costs

According to the pricing page, Extended Support costs 0.07 US dollars per vCore and hour in the first two years and 0.14 US dollars from the third year. At 730 hours that is 51.10 and 102.20 US dollars per vCore and month.

• Server with 4 vCores (D4ds_v5, list price 259.88 US dollars a month): plus 204.40 US dollars, about 79 percent more.
• From February 2029 for the same server: plus 408.80 US dollars a month.
• Server with 16 vCores: plus 817.60 US dollars a month in the first two years.

Charges apply only while a server is running in the Succeeded state. Stopped, deleted or failed servers incur no Extended Support. Upgrading mid month means paying only for the time until the upgrade. Whether the standby server counts with high availability is not stated on the pricing page. That should be clarified before budgeting.

What Extended Support includes and what it does not

It includes security updates, critical bug fixes and technical support under your existing support plan, until 11 November 2029 at the latest. It does not include new features, performance enhancements, general bug fixes, performance tuning assistance or minor version upgrades. Microsoft itself describes Extended Support as a temporary bridge until the upgrade.

Why PostgreSQL 15 as a target buys little time

Azure supports the newer versions until the end of community maintenance. Moving only to version 15 now means facing the same problem again in November 2027.

An in-place upgrade may skip versions. Version 17 is supported until November 2029, version 18 until November 2030. For most environments a direct move to 17 or 18 makes more sense than two upgrades within a year. TimescaleDB is an exception: from 14, Azure allows an in-place upgrade only to 15 or 16.

Finding the affected servers

This Azure Resource Graph query lists every Flexible Server on a version without standard support, including 11 to 13, which have been in Extended Support since August 2026.

resources
| where type =~ 'microsoft.dbforpostgresql/flexibleservers'
| extend version = tostring(properties.version)
| where version in ('11', '12', '13', '14')
| project name, resourceGroup, location, version, sku = tostring(sku.name),
    ha = tostring(properties.highAvailability.mode), state = tostring(properties.state)
| order by version asc

The vCores follow from the SKU name, D4ds_v5 for example has 4 vCores. The Azure portal also flags servers approaching end of support or already in Extended Support.

Preparing the upgrade

• Run the upgrade validation in the portal or with the Azure CLI. It finds blocking extensions, replication slots, event triggers and pending configuration changes, without downtime.
• Check extensions. session_variable, anon and age block every upgrade, pg_repack, hypopg and pg_partman have to be dropped before and recreated after.
• Delete read replicas before the upgrade and recreate them afterwards. With high availability, Azure disables HA and re-enables it after the upgrade, which needs capacity for a new standby.
• Ensure 10 to 20 percent free storage and check network rules for ports 5432 and 6432 and access to Azure Storage.
• Rehearse in a test environment restored from a point-in-time recovery. After the upgrade, the only way back is a restore to a new server.
• After the upgrade, run ANALYZE in every database so statistics are current.

If regional capacity constraints prevent the upgrade, Microsoft says a server may be temporarily excluded from billing. This goes through support.

Deciding server by server

The cost and migration analysis inventories every affected server across your subscriptions, calculates Extended Support through 2029 and sets the target version and order per server. The upgrade itself is carried out by your team or your service provider.