Azure Database for PostgreSQL and MySQL pricing

Azure Database for PostgreSQL and Azure Database for MySQL, both as Flexible Server, bill compute per vCore and hour in the Burstable, General Purpose and Memory Optimized tiers, provisioned storage per GiB and month, IOPS and throughput above the included level, backup storage beyond 100 percent of the provisioned storage, and with high availability a standby with the same compute and storage; Azure Database for PostgreSQL pricing and its MySQL counterpart follow the same cut. The vCores are the largest line, because they run around the clock and a standby doubles them; storage and backups keep billing while a server is stopped.

Pricing dimensions

The two services share the model but differ in limits and names: MySQL calls its top tier Memory Optimized in the documentation and Business Critical on the pricing page, and its storage and IOPS options differ. The table names both where they diverge; what all managed databases share is covered under managed databases.

Compute is tier times series times vCores. Burstable runs on B series with 1 to 20 vCores and a credit model that banks credits below the baseline and spends them above it; once they are gone only the baseline remains, so Microsoft does not recommend the tier for production and gives it neither high availability nor, on MySQL, read replicas. General Purpose offers 4 GiB per vCore on D series, Memory Optimized 6.75 to 9.5 GiB (MySQL 8 GiB) on E series, in several hardware generations with their own price per vCore. vCores change up and down at any time, storage only up.

High availability provisions a standby with the same configuration, zone-redundant in another availability zone or in the same zone; for MySQL Microsoft states outright that compute and storage are paid for both primary and standby, and for PostgreSQL the portal shows the standby's cost increase when it is enabled. The standby cannot be read from, and backups are kept and billed once regardless.

Storage is provisioned capacity, not used capacity: whatever was grown, by hand or by autogrow, stays billed. On MySQL autogrow is on by default and grows below 100 GB by 5 GB once less than 10 percent is free, above it by 5 percent once less than 10 GB is free; on servers with high availability it cannot be switched off. IOPS follow the storage size: Premium SSD brings fixed IOPS per size (120 at 32 GiB, 5,000 at 1 TiB), more cost per provisioned IOPS and month; Premium SSD v2 includes the first 3,000 IOPS (12,000 from 512 GiB) and bills per IOPS and per MB/s beyond. MySQL offers pre-provisioned additional IOPS or autoscale IOPS billed per million I/O operations.

Backup storage is free up to 100 percent of the provisioned storage: a server with 250 GiB has 250 GiB of backup storage included, ten days at 25 GiB of daily backup. Beyond it every GB costs per month, and heavy transaction load writes more WAL or binlog whatever the database size. Geo-redundant backup copies everything to the paired region, the backup size doubles, and Microsoft bills it as ((2 × local size) − provisioned storage) × price.

Stopping saves compute only: a stopped PostgreSQL server is started automatically after seven days, a MySQL server after 30, and in the meantime provisioned storage and backup storage keep billing, on MySQL provisioned IOPS too; MySQL's backup allowance applies to active servers only. Reserved capacity cuts the vCore price by up to 65 percent for one or three years, applies per region and tier with vCore size flexibility within the tier, and covers neither storage nor backup nor networking; the mechanics are under Azure reservations.

How it appears in your billing data

In the cost export the lines carry MeterCategory Azure Database for PostgreSQL or Azure Database for MySQL; the resource is the server (Microsoft.DBforPostgreSQL/flexibleServers, Microsoft.DBforMySQL/flexibleServers). The standby of a high-availability configuration has no resource of its own: its vCores and storage sit on the primary's meters, which then show twice the quantity. A read replica is a server with its own resource ID. The Retail Prices API lists the same meters; its serviceName, productName and meterName are the export's MeterCategory, ProductName and MeterName.

Three things land elsewhere: long-term retention through Azure Backup appears as PostgreSQL Protected Instance under MeterCategory Backup (Azure Backup and Site Recovery pricing), private endpoints are billed by Private Link and outbound data transfer sits on the bandwidth meters (Azure bandwidth and networking pricing), and diagnostic logs in a Log Analytics workspace are paid under Azure Monitor (Azure Monitor and Log Analytics pricing). In the FOCUS export the rows carry ServiceName Azure Database for PostgreSQL or Azure Database for MySQL, ServiceCategory Databases and ChargeCategory Usage; a reservation is a row with ChargeCategory Purchase, and the vCore hours it covers carry its CommitmentDiscountId. The export is explained under Azure cost exports, the columns under FOCUS columns and the providers' mapping.

Levers

Configuration:

• Tier and size by utilisation. vCores change in seconds; a development database belongs in Burstable, a production database with steady CPU load in the smallest General Purpose size that carries it. The method is rightsizing.
• Stop servers outside working hours. Stopping sets the vCore hours to zero, PostgreSQL for at most seven days at a time, MySQL for 30; storage and backup keep running. Schedules for it are under scheduling and auto-scaling.
• Provision storage tightly, switch autogrow on. Provisioned storage is billed, not used storage, and it never shrinks; autogrow adds small steps when needed, and Premium SSD v2 removes the fixed size steps and includes 3,000 IOPS. The patterns are under storage optimisation.
• Check backup retention and redundancy. Every day beyond seven and every geo-redundant copy grows backup storage past the allowance; the Backup Storage Used metric shows where it stands.

Purchase option:

• Reserved capacity for production servers. Up to 65 percent on the vCores of a tier and region, with size flexibility within the tier; storage and backup stay at list price. How much of it a commitment should cover is the subject of commitment strategy.

Architecture:

• High availability only where the SLA demands it. The standby doubles vCores and storage and cannot be read from; test and staging servers rarely need it. The trade-off belongs in architecture choices and cost.
• Count read replicas. Every replica is a full server; a reporting replica that only reads at month end costs the whole month. Further patterns are under database optimisation.
• Keep the major version current. Past community end of support Microsoft bills Extended Support per vCore and hour on top of compute.

Where it goes wrong

• The stopped server keeps costing. Symptom: a server stopped days ago produces storage and backup lines. Cause: only compute stops; provisioned storage, backup storage and on MySQL provisioned IOPS keep running, and after seven (PostgreSQL) or 30 days (MySQL) the server starts on its own.
• High availability doubles. Symptom: a server's vCore and storage quantity is twice what its configuration suggests. Cause: the standby sits on the primary's meters.
• Storage grows and never shrinks. Symptom: the storage line climbs in steps and stays up although data was deleted. Cause: autogrow or a manual increase; storage scales up only.
• Backup storage beyond the allowance. Symptom: a Backup Storage line on a server with a small database. Cause: long retention, a geo-redundant copy or heavy transaction load that writes more WAL or binlog than the database is large.
• Extended Support appears. Symptom: a new line per vCore hour next to compute. Cause: the major version reached community end of support.
• Burstable in production. Symptom: the server slows or becomes unreachable, and an upgrade follows the month after. Cause: the CPU credits are spent and the tier runs on its baseline.

Example

Germany West Central, list prices in EUR from the Azure Retail Prices API, read on 2026-10-21. PostgreSQL Flexible Server: General Purpose Ddsv5 EUR 0.0933 per vCore and hour (4 vCores EUR 0.3731), Memory Optimized Edsv5 EUR 0.1329 per vCore and hour, Burstable B1ms EUR 0.0175 and B2s EUR 0.07 per hour; storage EUR 0.1206 per GiB and month, additional IOPS EUR 0.0524 per IOPS and month, Premium SSD v2 IOPS EUR 0.0229; backup storage LRS EUR 0.0906 per GB and month; Extended Support EUR 0.0801 per vCore and hour. MySQL Flexible Server: General Purpose Ddsv5 EUR 0.0893 and Memory Optimized Edsv5 EUR 0.1257 per vCore and hour, B1ms EUR 0.0175 per hour, storage EUR 0.1206 per GB and month, additional IOPS EUR 0.0524 per IOPS and month, autoscale IOPS EUR 0.2288 per million I/O operations, backup storage EUR 0.0906 per GB and month. A PostgreSQL server on D4ds_v5 with 256 GiB of storage costs 0.3731 × 730 = EUR 272.36 plus 256 × 0.1206 = EUR 30.87 over 730 hours, EUR 303.24 in total; with zone-redundant high availability compute and storage double to EUR 606.47 while the backup is kept once. The standby is the single most expensive switch in the service.

Sources

Read on 2026-10-21. Microsoft, PostgreSQL: Azure Database for PostgreSQL Flexible Server pricing, Compute options, Storage options, Backup and restore, High availability, Configure high availability, Stop compute of a server, Prepay for compute resources with reserved capacity. MySQL: Azure Database for MySQL Flexible Server pricing, Service tiers, Storage IOPS, Backup and restore, High availability, Stop and start a server. Billing data: Understand cost details fields, FOCUS cost and usage details file schema, Azure Retail Prices REST API. Prices: Retail Prices query for Azure Database for PostgreSQL in Germany West Central in EUR, Retail Prices query for Azure Database for MySQL in Germany West Central in EUR.