Azure Database for PostgreSQL flexible server: Service and subscription limits — Issue with Burstable SKUs in East US 2

Hi @Jon-9536

This isn’t an unsupported tier transition. Azure Database for PostgreSQL Flexible Server supports scaling between General Purpose and Burstable tiers. Since high availability is disabled, the documented restriction that Burstable servers don’t support HA also isn’t the blocker.

However, quota and allocation capacity are separate checks. PostgreSQL scaling can be prevented by regional capacity constraints even when the subscription has sufficient quota. Also, SkuNotAvailable means that the requested SKU is unavailable for the subscription in the selected location or availability zone.

The consistent failure on both new deployments and existing-server scaling therefore points to a regional, zonal, or subscription-specific allocation restriction. That is an inference from the reported behavior.

Also note that near-zero-downtime scaling isn’t supported when scaling to or from one- or two-vCore Burstable SKUs. Azure uses the regular scaling process instead. That explains why the operation might require a restart, but it doesn’t explain why the operation has remained in Updating for several days.

At this stage, I recommend:

1. Check Azure Service Health for PostgreSQL incidents or advisories affecting East US 2.
2. In the resource group’s Activity log, open the failed scale operation and retain its complete error details, timestamp, and correlation/request ID.
3. Open an Azure support request for Azure Database for PostgreSQL Flexible Server → Compute scaling/deployment. Ask support to:
   1. confirm whether Standard_B2s or Standard_B2ms has an allocation or subscription restriction in East US 2;
   2. inspect the PostgreSQL resource-provider operation that remains in Updating;
   3. safely complete or roll back that operation before another scale attempt.

Include the server resource ID, subscription ID, requested SKU, zone selection, UTC timestamps, correlation IDs, and the complete SkuNotAvailable response. Create the request from the affected resource under Support + Troubleshooting.

Until the pending operation is cleared, don’t initiate another scale operation against that server. If an immediate workaround is required, select another available SKU, location, or zone, or submit a SKU request to Azure Support.

References:

• Scaling resources in Azure Database for PostgreSQL Flexible Server
• Scale compute resources in Azure Database for PostgreSQL Flexible Server
• Compute options in Azure Database for PostgreSQL Flexible Server
• Configure high availability
• Resolve “SKU not available” errors
• Find Azure Resource Manager error codes
• Azure Database for PostgreSQL business continuity

Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution. Thank you.

Hi,

Unfortunately new deployments of PostgreSQL Flexible Server Burstable SKUs are blocked in some regions (East US 2 is one). You are attempting to change existing deployment to Burstable, which is basically the same and blocked as well.

The only way around it in my experience is to use a different SKU such as General Purpose or deploy in a different region that isn't blocked yet. It isn't only your subscription, or only East US 2 region.

Since you are already on General Purpose then I would suggest staying with existing SKU and possibly purchasing 3 year reservation to reduce cost.

Below is excerpt from documentation on how to resolve this error:

SKU not available

If you encounter the following error, select a different SKU type. Availability of SKU may differ across regions, either the specific SKU isn't supported in the region or temporarily unavailable. Specified SKU is not supported in this region. Please choose a different SKU.

To provide more context, the underlying VM sizes for PostgreSQL Flexible Burstable SKUs are being retired, and they are currently subject to growth restrictions and capacity limitations. Many subscriptions are blocked from creating these sizes at all, whereas others that already have them are unable to get additional quota and/or may see failures if they deallocate and try to start VM later.

Please see Quotas screenshot below. Note how Burstable (standardBSFamily) is End of Life:

There hasn't been official guidance that I am aware of as to what will happen and when with these Burstable SKUs. For instance, there are Bsv2 burstable VM sizes that are supposed to replace the retiring ones. Will they switch PostgreSQL Flexible to use these as the underlying VMs for Burstable SKUs at some point? By the way, these Bsv2 series sizes can be difficult to obtain quota for, even though they are not deprecated.

Recently I was able to create PostgreSQL Burstable SKU in West US 2, which is in part why I know that not all regions are blocking them (yet). In months past I've created them in other regions as well, but I don't remember specific regions.

Please click Accept Answer and upvote if the above was helpful.

Thanks.

-TP