"Capacity is not available in this region/zone. Please retry after some time." error when trying to scale across compute tiers

Question

"Capacity is not available in this region/zone. Please retry after some time." error when trying to scale across compute tiers

JK 10

Running into the following error when trying to scale up a Azure Database for PostgreSQL flexible server.

{
  "code": "CapacityNotAvailable",
  "message": "Capacity is not available in this region/zone. Please retry after some time."
}

Going from Standard_B1ms to ANY SKU fails (Standard_D2ds_v5, Standard_D2ds_v4, Standard_D2ds_v3, Standard_D2ads_v5)
Scaling up within Burstable also fails (Standard_B2s)
Tried many times over multiple days
East US

All of the SKUs are available when I run az postgres flexible-server list-skus --location eastus

I also requested and was granted Region access quota in East US a while ago and was successful.

Pilladi Padma Sai Manisha 11,715 Reputation points Microsoft External Staff Moderator

2026-03-18T19:21:31.88+00:00

Hi JK,
Thankyou for reaching microsoft Q&A!

Could you please try from different region like us west 3
please let me know if issue persists.
JK 10 Reputation points

2026-03-18T20:08:07.7+00:00

Moving to a different region is not an option. This DB needs to be in the same vnet as other resources.
JK 10 Reputation points

2026-03-18T21:30:45.58+00:00
I can't stop the server. It says "Stop feature is temporarily disabled in East US due to capacity constraints"

I can't scale in smaller steps, because as I mentioned, even scaling up within the same tier to Standard_B2s fails
Pilladi Padma Sai Manisha 11,715 Reputation points Microsoft External Staff Moderator

2026-03-23T20:12:59.74+00:00

Hi JK,
Thanks for confirming the additional details that helps narrow this down.

Since scaling fails across all SKUs (including within the same tier), stop/start is blocked due to capacity constraints, SKU availability shows correctly via CLI, and retries over several days didn’t succeed, this points to a hard capacity constraint in the specific stamp or availability zone where the server is currently allocated. In this situation, the platform is unable to move your server to alternate infrastructure with available capacity.

At this point, there are no remaining in-place mitigation options. You’re effectively blocked because the service cannot reassign compute, and operations like scaling or stopping the server,which would normally help are themselves restricted due to the same capacity issue.

In such scenarios, the only viable resolution is what you already did: recreating the server. A new deployment allows Azure to place the server on available capacity in a different underlying cluster or zone.

This is an edge case where an existing server becomes “stuck” on constrained infrastructure with no relocation path. Unfortunately, when that happens, recreate is the only reliable way forward.
Pilladi Padma Sai Manisha 11,715 Reputation points Microsoft External Staff Moderator

2026-03-24T22:08:41.1533333+00:00

Hi JK,
I hope you had a chance to review the information shared earlier, and I hope this information has been helpful! If you still have questions, please let us know what is needed in the comments so the question can be answered.

2 answers

Your answer

Pilladi Padma Sai Manisha 11,715 Reputation points Microsoft External Staff Moderator

2026-03-18T19:21:31.88+00:00

Hi JK,
Thankyou for reaching microsoft Q&A!

Could you please try from different region like us west 3
please let me know if issue persists.
JK 10 Reputation points

2026-03-18T20:08:07.7+00:00

Moving to a different region is not an option. This DB needs to be in the same vnet as other resources.
JK 10 Reputation points

2026-03-18T21:30:45.58+00:00

I can't stop the server. It says "Stop feature is temporarily disabled in East US due to capacity constraints"

I can't scale in smaller steps, because as I mentioned, even scaling up within the same tier to Standard_B2s fails
Pilladi Padma Sai Manisha 11,715 Reputation points Microsoft External Staff Moderator

2026-03-23T20:12:59.74+00:00

Hi JK,
Thanks for confirming the additional details that helps narrow this down.

Since scaling fails across all SKUs (including within the same tier), stop/start is blocked due to capacity constraints, SKU availability shows correctly via CLI, and retries over several days didn’t succeed, this points to a hard capacity constraint in the specific stamp or availability zone where the server is currently allocated. In this situation, the platform is unable to move your server to alternate infrastructure with available capacity.

At this point, there are no remaining in-place mitigation options. You’re effectively blocked because the service cannot reassign compute, and operations like scaling or stopping the server,which would normally help are themselves restricted due to the same capacity issue.

In such scenarios, the only viable resolution is what you already did: recreating the server. A new deployment allows Azure to place the server on available capacity in a different underlying cluster or zone.

This is an edge case where an existing server becomes “stuck” on constrained infrastructure with no relocation path. Unfortunately, when that happens, recreate is the only reliable way forward.
Pilladi Padma Sai Manisha 11,715 Reputation points Microsoft External Staff Moderator

2026-03-24T22:08:41.1533333+00:00

Hi JK,
I hope you had a chance to review the information shared earlier, and I hope this information has been helpful! If you still have questions, please let us know what is needed in the comments so the question can be answered.

Answer 1

Thanks for clarifying , completely understand that moving regions isn’t an option due to the VNet dependency.

Given everything you’ve already validated (multiple SKUs + CLI showing availability), this points to capacity pressure at the zone/cluster level within East US, not quota or SKU access.

Since you need to stay in the same region, you can try a few targeted workarounds:

Switch Availability Zone (or temporarily remove zone pinning, if configured)

Stop > Start the server, then retry scaling (this can sometimes land the server on different underlying capacity)
Try scaling in smaller steps (e.g., B1ms > B2s > D-series), instead of jumping directly

Retry during different time windows, as capacity can fluctuate within the region

Also worth noting: even though SKUs appear available via CLI, they may not be available in the specific zone your server is currently allocated to, which is why all scale attempts can fail.

Hope this helps narrow it down a bit further.

Answer 2

JK 10

None of the solutions offered worked. Had to re-create the database from scratch.

0 comments