Compute and storage options in Azure Database for PostgreSQL - Flexible Server
APPLIES TO:
Azure Database for PostgreSQL - Flexible Server
You can create an Azure Database for PostgreSQL server in one of three pricing tiers: Burstable, General Purpose, and Memory Optimized. The pricing tiers are differentiated by the amount of compute in vCores that you can provision, the amount of memory per vCore, and the storage technology that's used to store the data. All resources are provisioned at the PostgreSQL server level. A server can have one or many databases.
Resource/Tier | Burstable | General Purpose | Memory Optimized |
---|---|---|---|
VM-series | B-series | Ddsv4-series, Dsv3-series |
Edsv4-series, Esv3-series |
vCores | 1, 2, 4, 8, 12, 16, 20 | 2, 4, 8, 16, 32, 48, 64 | 2, 4, 8, 16, 20 (v4), 32, 48, 64 |
Memory per vCore | Variable | 4 GB | 6.75 GB to 8 GB |
Storage size | 32 GB to 32 TB | 32 GB to 32 TB | 32 GB to 32 TB |
Database backup retention period | 7 to 35 days | 7 to 35 days | 7 to 35 days |
To choose a pricing tier, use the following table as a starting point:
Pricing tier | Target workloads |
---|---|
Burstable | Workloads that don't need the full CPU continuously. |
General Purpose | Most business workloads that require balanced compute and memory with scalable I/O throughput. Examples include servers for hosting web and mobile apps and other enterprise applications. |
Memory Optimized | High-performance database workloads that require in-memory performance for faster transaction processing and higher concurrency. Examples include servers for processing real-time data and high-performance transactional or analytical apps. |
After you create a server for the compute tier, you can change the number of vCores (up or down) and the storage size (up) in seconds. You also can independently adjust the backup retention period up or down. For more information, see the Scaling resources section.
Compute tiers, vCores, and server types
You can select compute resources based on the tier, vCores, and memory size. vCores represent the logical CPU of the underlying hardware.
The detailed specifications of the available server types are as follows:
SKU name | vCores | Memory size | Maximum supported IOPS | Maximum supported I/O bandwidth |
---|---|---|---|---|
Burstable | ||||
B1ms | 1 | 2 GiB | 640 | 10 MiB/sec |
B2s | 2 | 4 GiB | 1,280 | 15 MiB/sec |
B2ms | 2 | 4 GiB | 1,700 | 22.5 MiB/sec |
B4ms | 4 | 8 GiB | 2,400 | 35 MiB/sec |
B8ms | 8 | 16 GiB | 3,100 | 50 MiB/sec |
B12ms | 12 | 24 GiB | 3,800 | 50 MiB/sec |
B16ms | 16 | 32 GiB | 4,300 | 50 MiB/sec |
B20ms | 20 | 40 GiB | 5,000 | 50 MiB/sec |
General Purpose | ||||
D2s_v3 / D2ds_v4 / D2ds_v5 | 2 | 8 GiB | 3,200 | 48 MiB/sec |
D4s_v3 / D4ds_v4 / D4ds_v5 | 4 | 16 GiB | 6,400 | 96 MiB/sec |
D8s_v3 / D8ds_v4 / D8ds_v5 | 8 | 32 GiB | 12,800 | 192 MiB/sec |
D16s_v3 / D16ds_v4 / D16ds_v5 | 16 | 64 GiB | 20,000 | 384 MiB/sec |
D32s_v3 / D32ds_v4 / D32ds_v5 | 32 | 128 GiB | 20,000 | 768 MiB/sec |
D48s_v3 / D48ds_v4 / D48ds_v5 | 48 | 192 GiB | 20,000 | 900 MiB/sec |
D64s_v3 / D64ds_v4 / D64ds_v5 | 64 | 256 GiB | 20,000 | 900 MiB/sec |
D96ds_v5 | 96 | 384 GiB | 20,000 | 900 MiB/sec |
Memory Optimized | ||||
E2s_v3 / E2ds_v4 / E2ds_v5 | 2 | 16 GiB | 3,200 | 48 MiB/sec |
E4s_v3 / E4ds_v4 / E4ds_v5 | 4 | 32 GiB | 6,400 | 96 MiB/sec |
E8s_v3 / E8ds_v4 / E8ds_v5 | 8 | 64 GiB | 12,800 | 192 MiB/sec |
E16s_v3 / E16ds_v4 / E16ds_v5 | 16 | 128 GiB | 20,000 | 384 MiB/sec |
E20ds_v4 / E20ds_v5 | 20 | 160 GiB | 20,000 | 480 MiB/sec |
E32s_v3 / E32ds_v4 / E32ds_v5 | 32 | 256 GiB | 20,000 | 768 MiB/sec |
E48s_v3 / E48ds_v4 / E48ds_v5 | 48 | 384 GiB | 20,000 | 900 MiB/sec |
E64s_v3 / E64ds_v4 | 64 | 432 GiB | 20,000 | 900 MiB/sec |
E64ds_v5 | 64 | 512 GiB | 20,000 | 900 MiB/sec |
E96ds_v5 | 96 | 672 GiB | 20,000 | 900 MiB/sec |
Storage
The storage that you provision is the amount of storage capacity available to your Azure Database for PostgreSQL server. The storage is used for the database files, temporary files, transaction logs, and PostgreSQL server logs. The total amount of storage that you provision also defines the I/O capacity available to your server.
Storage is available in the following fixed sizes:
Disk size | IOPS |
---|---|
32 GiB | Provisioned 120; up to 3,500 |
64 GiB | Provisioned 240; up to 3,500 |
128 GiB | Provisioned 500; up to 3,500 |
256 GiB | Provisioned 1,100; up to 3,500 |
512 GiB | Provisioned 2,300; up to 3,500 |
1 TiB | 5,000 |
2 TiB | 7,500 |
4 TiB | 7,500 |
8 TiB | 16,000 |
16 TiB | 18,000 |
32 TiB | 20,000 |
Your VM type also constrains IOPS. Even though you can select any storage size independently from the server type, you might not be able to use all IOPS that the storage provides, especially when you choose a server with a small number of vCores.
You can add storage capacity during and after the creation of the server.
Note
Storage can only be scaled up, not down.
You can monitor your I/O consumption in the Azure portal or by using Azure CLI commands. The relevant metrics to monitor are storage limit, storage percentage, storage used, and I/O percentage.
Maximum IOPS for your configuration
SKU name | Storage size in GiB | 32 | 64 | 128 | 256 | 512 | 1,024 | 2,048 | 4,096 | 8,192 | 16,384 | 32,767 |
---|---|---|---|---|---|---|---|---|---|---|---|---|
Maximum IOPS | 120 | 240 | 500 | 1,100 | 2,300 | 5,000 | 7,500 | 7,500 | 16,000 | 18,000 | 20,000 | |
Burstable | ||||||||||||
B1ms | 640 IOPS | 120 | 240 | 500 | 640* | 640* | 640* | 640* | 640* | 640* | 640* | 640* |
B2s | 1,280 IOPS | 120 | 240 | 500 | 1,100 | 1,280* | 1,280* | 1,280* | 1,280* | 1,280* | 1,280* | 1,280* |
B2ms | 1,280 IOPS | 120 | 240 | 500 | 1,100 | 1,700* | 1,700* | 1,700* | 1,700* | 1,700* | 1,700* | 1,700* |
B4ms | 1,280 IOPS | 120 | 240 | 500 | 1,100 | 2,300 | 2,400* | 2,400* | 2,400* | 2,400* | 2,400* | 2,400* |
B8ms | 1,280 IOPS | 120 | 240 | 500 | 1,100 | 2,300 | 3,100* | 3,100* | 3,100* | 3,100* | 2,400* | 2,400* |
B12ms | 1,280 IOPS | 120 | 240 | 500 | 1,100 | 2,300 | 3,800* | 3,800* | 3,800* | 3,800* | 3,800* | 3,800* |
B16ms | 1,280 IOPS | 120 | 240 | 500 | 1,100 | 2,300 | 4,300* | 4,300* | 4,300* | 4,300* | 4,300* | 4,300* |
B20ms | 1,280 IOPS | 120 | 240 | 500 | 1,100 | 2,300 | 5,000 | 5,000* | 5,000* | 5,000* | 5,000* | 5,000* |
General Purpose | ||||||||||||
D2s_v3 / D2ds_v4 | 3,200 IOPS | 120 | 240 | 500 | 1,100 | 2,300 | 3,200* | 3,200* | 3,200* | 3,200* | 3,200* | 3,200* |
D2ds_v5 | 3,750 IOPS | 120 | 240 | 500 | 1,100 | 2,300 | 3,200* | 3,200* | 3,200* | 3,200* | 3,200* | 3,200* |
D4s_v3 / D4ds_v4 / D4ds_v5 | 6,400 IOPS | 120 | 240 | 500 | 1,100 | 2,300 | 5,000 | 6,400* | 6,400* | 6,400* | 6,400* | 6,400* |
D8s_v3 / D8ds_v4 / D8ds_v5 | 12,800 IOPS | 120 | 240 | 500 | 1,100 | 2,300 | 5,000 | 7,500 | 7,500 | 12,800* | 12,800* | 12,800* |
D16s_v3 / D16ds_v4 / D16ds_v5 | 20,000 IOPS | 120 | 240 | 500 | 1,100 | 2,300 | 5,000 | 7,500 | 7,500 | 16,000 | 18,000 | 20,000 |
D32s_v3 / D32ds_v4 / D32ds_v5 | 20,000 IOPS | 120 | 240 | 500 | 1,100 | 2,300 | 5,000 | 7,500 | 7,500 | 16,000 | 18,000 | 20,000 |
D48s_v3 / D48ds_v4 / D48ds_v5 | 20,000 IOPS | 120 | 240 | 500 | 1,100 | 2,300 | 5,000 | 7,500 | 7,500 | 16,000 | 18,000 | 20,000 |
D64s_v3 / D64ds_v4 / D64ds_v5 | 20,000 IOPS | 120 | 240 | 500 | 1,100 | 2,300 | 5,000 | 7,500 | 7,500 | 16,000 | 18,000 | 20,000 |
D96ds_v5 | 20,000 IOPS | 120 | 240 | 500 | 1,100 | 2,300 | 5,000 | 7,500 | 7,500 | 16,000 | 18,000 | 20,000 |
Memory Optimized | ||||||||||||
E2s_v3 / E2ds_v4 | 3,200 IOPS | 120 | 240 | 500 | 1,100 | 2,300 | 3,200* | 3,200* | 3,200* | 3,200* | 3,200* | 3,200* |
E2ds_v5 | 3,750 IOPS | 120 | 240 | 500 | 1,100 | 2,300 | 3,200* | 3,200* | 3,200* | 3,200* | 3,200* | 3,200* |
E4s_v3 / E4ds_v4 / E4ds_v5 | 6,400 IOPS | 120 | 240 | 500 | 1,100 | 2,300 | 5,000 | 6,400* | 6,400* | 6,400* | 6,400* | 6,400* |
E8s_v3 / E8ds_v4 / E8ds_v5 | 12,800 IOPS | 120 | 240 | 500 | 1,100 | 2,300 | 5,000 | 7,500 | 7,500 | 12,800* | 12,800* | 12,800* |
E16s_v3 / E16ds_v4 / E16ds_v5 | 20,000 IOPS | 120 | 240 | 500 | 1100 | 2,300 | 5,000 | 7,500 | 7,500 | 16,000 | 18,000 | 20,000 |
E20ds_v4/E20ds_v5 | 20,000 IOPS | 120 | 240 | 500 | 1,100 | 2,300 | 5,000 | 7,500 | 7,500 | 16,000 | 18,000 | 20,000 |
E32s_v3 / E32ds_v4 / E32ds_v5 | 20,000 IOPS | 120 | 240 | 500 | 1,100 | 2,300 | 5,000 | 7,500 | 7,500 | 16,000 | 18,000 | 20,000 |
E48s_v3 / E48ds_v4 / E48ds_v5 | 20,000 IOPS | 120 | 240 | 500 | 1,100 | 2,300 | 5,000 | 7,500 | 7,500 | 16,000 | 18,000 | 20,000 |
E64s_v3 / E64ds_v4 / E64ds_v5 | 20,000 IOPS | 120 | 240 | 500 | 1,100 | 2,300 | 5,000 | 7,500 | 7,500 | 16,000 | 18,000 | 20,000 |
E96ds_v5 | 20,000 IOPS | 120 | 240 | 500 | 1,100 | 2,300 | 5,000 | 7,500 | 7,500 | 16,000 | 18,000 | 20,000 |
IOPS marked with an asterisk (*) are limited by the VM type that you selected. Otherwise, the selected storage size limits the IOPS.
Note
You might see higher IOPS in the metrics because of disk-level bursting. For more information, see Managed disk bursting.
Maximum I/O bandwidth (MiB/sec) for your configuration
SKU name | Storage size in GiB | 32 | 64 | 128 | 256 | 512 | 1,024 | 2,048 | 4,096 | 8,192 | 16,384 | 32,767 |
---|---|---|---|---|---|---|---|---|---|---|---|---|
Storage bandwidth in MiB/sec | 25 | 50 | 100 | 125 | 150 | 200 | 250 | 250 | 500 | 750 | 900 | |
Burstable | ||||||||||||
B1ms | 10 MiB/sec | 10* | 10* | 10* | 10* | 10* | 10* | 10* | 10* | 10* | 10* | 10* |
B2s | 15 MiB/sec | 15* | 15* | 15* | 15* | 15* | 15* | 15* | 15* | 15* | 10* | 10* |
B2ms | 22.5 MiB/sec | 22.5* | 22.5* | 22.5* | 22.5* | 22.5* | 22.5* | 22.5* | 22.5* | 22.5* | 22.5* | 22.5* |
B4ms | 35 MiB/sec | 25 | 35* | 35* | 35* | 35* | 35* | 35* | 35* | 35* | 35* | 35* |
B8ms | 50 MiB/sec | 25 | 50 | 50* | 50* | 50* | 50* | 50* | 50* | 50* | 50* | 50* |
B12ms | 50 MiB/sec | 25 | 50 | 50* | 50* | 50* | 50* | 50* | 50* | 50* | 50* | 50* |
B16ms | 50 MiB/sec | 25 | 50 | 50* | 50* | 50* | 50* | 50* | 50* | 50* | 50* | 50* |
B20ms | 50 MiB/sec | 25 | 50 | 50* | 50* | 50* | 50* | 50* | 50* | 50* | 50* | 50* |
General Purpose | ||||||||||||
D2s_v3 / D2ds_v4 | 48 MiB/sec | 25 | 48* | 48* | 48* | 48* | 48* | 48* | 48* | 48* | 48* | 48* |
D2ds_v5 | 85 MiB/sec | 25 | 50 | 85* | 85* | 85* | 85* | 85* | 85* | 85* | 85* | 85* |
D4s_v3 / D4ds_v4 | 96 MiB/sec | 25 | 50 | 96* | 96* | 96* | 96* | 96* | 96* | 96* | 96* | 96* |
D4ds_v5 | 145 MiB/sec | 25 | 50* | 100* | 125* 145* | 145* | 145* | 145* | 145* | 145* | 145* | |
D8s_v3 / D8ds_v4 | 192 MiB/sec | 25 | 50 | 100 | 125 | 150 | 192* | 192* | 192* | 192* | 192* | 192* |
D8ds_v5 | 290 MiB/sec | 25 | 50 | 100 | 125 | 150 | 200 | 250 | 250 | 290* | 290* | 290* |
D16s_v3 / D16ds_v4 | 384 MiB/sec | 25 | 50 | 100 | 125 | 150 | 200 | 250 | 250 | 384* | 384* | 384* |
D16ds_v5 | 600 MiB/sec | 25 | 50 | 100 | 125 | 150 | 200 | 250 | 250 | 500 | 600* | 600* |
D32s_v3 / D32ds_v4 | 768 MiB/sec | 25 | 50 | 100 | 125 | 150 | 200 | 250 | 250 | 500 | 750 | 900 |
D32ds_v5 | 865 MiB/sec | 25 | 50 | 100 | 125 | 150 | 200 | 250 | 250 | 500 | 750 | 865* |
D48s_v3 / D48ds_v4 /D48ds_v5 | 900 MiB/sec | 25 | 50 | 100 | 125 | 150 | 200 | 250 | 250 | 500 | 750 | 900 |
D64s_v3 / Dd64ds_v4 /D64ds_v5 | 900 MiB/sec | 25 | 50 | 100 | 125 | 150 | 200 | 250 | 250 | 500 | 750 | 900 |
Dd96ds_v5 | 900 MiB/sec | 25 | 50 | 100 | 125 | 150 | 200 | 250 | 250 | 500 | 750 | 900 |
Memory Optimized | ||||||||||||
E2s_v3 / E2ds_v4 | 48 MiB/sec | 25 | 48* | 48* | 48* | 48* | 48* | 48* | 48* | 48* | 48* | 48* |
E2ds_v5 | 85 MiB/sec | 25 | 50 | 85* | 85* | 85* | 85* | 85* | 85* | 85* | 85* | 85* |
E4s_v3 / E4ds_v4 | 96 MiB/sec | 25 | 50 | 96* | 96* | 96* | 96* | 96* | 96* | 96* | 96* | 96* |
E4ds_v5 | 145 MiB/sec | 25 | 50* | 100* | 125* 145* | 145* | 145* | 145* | 145* | 145* | 145* | |
E8s_v3 / E8ds_v4 | 192 MiB/sec | 25 | 50 | 100 | 125 | 150 | 192* | 192* | 192* | 192* | 192* | 192* |
E8ds_v5 | 290 MiB/sec | 25 | 50 | 100 | 125 | 150 | 200 | 250 | 250 | 290* | 290* | 290* |
E16s_v3 / E16ds_v4 | 384 MiB/sec | 25 | 50 | 100 | 125 | 150 | 200 | 250 | 250 | 384* | 384* | 384* |
E16ds_v5 | 600 MiB/sec | 25 | 50 | 100 | 125 | 150 | 200 | 250 | 250 | 500 | 600* | 600* |
E20ds_v4 | 480 MiB/sec | 25 | 50 | 100 | 125 | 150 | 200 | 250 | 250 | 480* | 480* | 480* |
E20ds_v5 | 750 MiB/sec | 25 | 50 | 100 | 125 | 150 | 200 | 250 | 250 | 500 | 750 | 750* |
E32s_v3 / E32ds_v4 | 750 MiB/sec | 25 | 50 | 100 | 125 | 150 | 200 | 250 | 250 | 500 | 750 | 750 |
E32ds_v5 | 865 MiB/sec | 25 | 50 | 100 | 125 | 150 | 200 | 250 | 250 | 500 | 750 | 865* |
E48s_v3 / E48ds_v4 /E48ds_v5 | 900 MiB/sec | 25 | 50 | 100 | 125 | 150 | 200 | 250 | 250 | 500 | 750 | 900 |
E64s_v3 / E64ds_v4 /E64ds_v5 | 900 MiB/sec | 25 | 50 | 100 | 125 | 150 | 200 | 250 | 250 | 500 | 750 | 900 |
Ed96ds_v5 | 900 MiB/sec | 25 | 50 | 100 | 125 | 150 | 200 | 250 | 250 | 500 | 750 | 900 |
I/O bandwidth marked with an asterisk (*) is limited by the VM type that you selected. Otherwise, the selected storage size limits the I/O bandwidth.
Reaching the storage limit
When you reach the storage limit, the server starts returning errors and prevents any further modifications. Reaching the limit might also cause problems with other operational activities, such as backups and write-ahead log (WAL) archiving.
To avoid this situation, the server is automatically switched to read-only mode when the storage usage reaches 95 percent or when the available capacity is less than 5 GiB.
We recommend that you actively monitor the disk space that's in use and increase the disk size before you run out of storage. You can set up an alert to notify you when your server storage is approaching an out-of-disk state. For more information, see Use the Azure portal to set up alerts on metrics for Azure Database for PostgreSQL - Flexible Server.
Storage auto-grow (preview)
Storage auto-grow can help ensure that your server always has enough storage capacity and doesn't become read-only. When you turn on storage auto-grow, the storage will automatically expand without affecting the workload. This feature is currently in preview.
For servers with more than 1 TiB of provisioned storage, the storage autogrow mechanism activates when the available space falls to less than 10% of the total capacity or 64 GiB of free space, whichever of the two values is smaller. Conversely, for servers with storage under 1 TB, this threshold is adjusted to 20% of the available free space or 64 GiB, depending on which of these values is smaller.
As an illustration, take a server with a storage capacity of 2 TiB ( greater than 1 TIB). In this case, the autogrow limit is set at 64 GiB. This choice is made because 64 GiB is the smaller value when compared to 10% of 2 TiB, which is roughly 204.8 GiB. In contrast, for a server with a storage size of 128 GiB (less than 1 TiB), the autogrow feature activates when there's only 25.8 GiB of space left. This activation is based on the 20% threshold of the total allocated storage (128 GiB), which is smaller than 64 GiB.
Azure Database for PostgreSQL - Flexible Server uses Azure managed disks. The default behavior is to increase the disk size to the next premium tier. This increase is always double in both size and cost, regardless of whether you start the storage scaling operation manually or through storage auto-grow. Enabling storage auto-grow is valuable when you're managing unpredictable workloads because it automatically detects low-storage conditions and scales up the storage accordingly.
The process of scaling storage is performed online without causing any downtime, except when the disk is provisioned at 4,096 GiB. This exception is a limitation of Azure Managed disks. If a disk is already 4,096 GiB, the storage scaling activity won't be triggered, even if storage auto-grow is turned on. In such cases, you need to manually scale your storage. Manual scaling is an offline operation that you should plan according to your business requirements.
Remember that storage can only be scaled up, not down.
Limitations
Disk scaling operations are always online, except in specific scenarios that involve the 4,096-GiB boundary. These scenarios include reaching, starting at, or crossing the 4,096-GiB limit. An example is when you're scaling from 2,048 GiB to 8,192 GiB.
This limitation is due to the underlying Azure managed disk, which needs a manual disk scaling operation. You receive an informational message in the portal when you approach this limit.
Storage auto-grow currently doesn't work for high-availability or read-replica-enabled servers.
Storage auto-grow isn't triggered when you have high WAL usage.
Note
Storage auto-grow never triggers an offline increase.
Backup
The service automatically takes backups of your server. You can select a retention period from a range of 7 to 35 days. To learn more about backups, see Backup and restore in Azure Database for PostgreSQL - Flexible Server.
Scaling resources
After you create your server, you can independently change the vCores, the compute tier, the amount of storage, and the backup retention period. You can scale the number of vCores up or down. You can scale the backup retention period up or down from 7 to 35 days. The storage size can only be increased. You can scale the resources through the Azure portal or the Azure CLI.
Note
After you increase the storage size, you can't go back to a smaller storage size.
When you change the number of vCores or the compute tier, the server is restarted for the new server type to take effect. During the moment when the system switches over to the new server, no new connections can be established, and all uncommitted transactions are rolled back.
The time it takes to restart your server depends on the crash recovery process and database activity at the time of the restart. Restarting typically takes one minute or less. But it can be higher and can take several minutes, depending on transactional activity at the time of the restart. Scaling the storage works the same way and requires a restart.
To improve the restart time, we recommend that you perform scale operations during off-peak hours. That approach reduces the time needed to restart the database server.
Changing the backup retention period is an online operation.
Pricing
For the most up-to-date pricing information, see the Azure Database for PostgreSQL pricing page. The Azure portal shows the monthly cost on the Pricing tier tab, based on the options that you select.
If you don't have an Azure subscription, you can use the Azure pricing calculator to get an estimated price. On the Azure pricing calculator website, select Add items, expand the Databases category, and then select Azure Database for PostgreSQL to customize the options.
Next steps
- Learn how to create a PostgreSQL server in the portal.
- Learn about service limits.
Feedback
Submit and view feedback for