Azure PostgreSQL Flexible Server dev-os-db ran out of provisioned storage

Question

This morning, the Azure PostgreSQL Flexible Server dev-os-db ran out of provisioned storage, which caused the database to reject writes and behave in read-only mode. We attempted to increase storage, but Azure blocked the operation in East US with LocationIsOfferRestricted, so the service could not be resized in-region. Root cause is storage exhaustion, with recovery currently blocked by an Azure regional provisioning restrictionWe need Region access for Azure Database for PostgreSQL Flexible Server in East US for subscription xxxx-xxxx-xxxx-xxxx-xxxxxxx. Existing server: dev-os-db in resource group dev-env. The server ran out of storage and entered read-only behavior for writes. A storage increase attempt failed with LocationIsOfferRestricted in East US. Please enable East US access for this subscription or advise the nearest supported region for immediate recovery.

Answer 1

Hi BRUCE AIESI,

Please be informed that the Auto grow feature will only activates when it is enabled for the server.
For servers with more than 1 TiB of provisioned storage, the storage autogrow mechanism activates when the available space is less than 10% of the total capacity or when the available space is less than 64 GiB. The smaller of the two is the value that determines when autogrow activates. Conversely, for servers with storage under 1 TiB, this threshold is adjusted to 20% of the total capacity or when the available space is less than 64 GiB. Again, picking the smaller of the two values.

Azure Database for PostgreSQL only supports the storage autogrow feature on storage type Premium SSD.

Storage always doubles in size for premium disk SSD, and that doubles the storage cost.

Only premium SSD V2 supports more granular disk size increase.

Limitations and considerations:

• Autogrow activates when available space is less than 10% of total provisioned storage or 64 GiB, whichever is greater.

https://learn.microsoft.com/en-us/azure/postgresql/scale/how-to-auto-grow-storage?tabs=portal-enable-existing-server%2Cportal-disable-existing-server%2Cportal-enable-new-server#steps-to-enable-storage-autogrow-for-existing-servers

Also, for EAST US region capacity issues, we recommend you to enable geo-backup or create a replica in another region that is not capacity constrained and move there.

Recommended alternate regions are:

• Central US
• Canada Central

https://learn.microsoft.com/en-us/azure/postgresql/read-replica/how-to-create-read-replica?tabs=portal-create-read-replica
https://docs.azure.cn/en-us/postgresql/backup-restore/concepts-backup-restore#geo-redundant-backup-and-restore

Answer 2

Resolution Summary

Visuals

I noticed in the Azure Portal that the database storage was rapidly increasing and had reached 98–100% utilization, which caused the database to enter a read-only state.

Storage

I attempted to increase the storage to 256 GB, but the operation failed with the error:

LocationIsOfferRestricted in region East US.

This prevented me from scaling the storage for the existing server.

Restore

To recover quickly, I attempted to restore the PostgreSQL Flexible Server (dev-os-db) using Azure’s restore functionality. However, I was unable to proceed because Geo-redundant backup was not configured for the source server. The other restore options appeared disabled, so I abandoned this approach since the storage increase was also blocked due to the East US region restriction.

Backup

I then began performing manual backups of the database using the pgAdmin4 backup utility, saving the backups locally to my laptop.

Redeploy

My next step was to deploy a new PostgreSQL Flexible Server manually.

I created a new server named pm-os-db in a different region (East US 2).

After deploying the new server, I:

Created the required database manually

Recreated the necessary user roles and permissions

Began restoring the database using pgAdmin4

Application

After the database was restored, I had to reconfigure the Azure App Services to point to the new database server.

I then manually redeployed the four Azure App Service web applications to bring the website back online.

Conclusion

The recovery process required a significant amount of manual work.

I expected Storage Autogrow to automatically increase storage from 128 GB to 256 GB, but this did not occur.

The Azure Backup and Restore functionality that I expected to rely on was not available because:

Storage scaling was blocked with LocationIsOfferRestricted in East US

Geo-redundant backups were not enabled on the original server.

Interestingly, the next morning the original dev-os-db PostgreSQL Flexible Server appears to be operational again for unknown reasons. Since I have already rebuilt the environment, I plan to delete the original server after verifying everything is stable.

Question

I also have a production PostgreSQL Flexible Server environment, currently at 60% storage utilization, and I want to avoid encountering the same issue.

In the past, I have seen Storage Autogrow work correctly. However, after this incident I am losing confidence in relying on it.

Could you please advise on best practices to ensure this does not occur again in production?

Answer 3

Hi BRUCE AIESI,

We recommend upgrading the server from Burstable to General Purpose, as General Purpose SKUs are less susceptible to regional capacity constraints and are better suited for storage‑ and performance‑sensitive workloads.

However, if the SKU upgrade is blocked due to regional capacity restrictions (such as the LocationIsOfferRestricted error you encountered in East US), the supported workaround is to restore or deploy the server in a different region where capacity is currently available, for example:

• Central US
• West US 2
• West US 3

To help prevent similar issues in the future, we recommend:

• Avoiding Burstable SKUs for production or growth‑sensitive workloads
• Using General Purpose SKUs for better availability and scalability
• Configuring storage utilization alerts well before the maximum limit is reached