PostgreSQL Flexible Server B1ms deployment fails with SkuNotAvailable in West US 3 despite appearing in Azure CLI

Benji Lentz 0 Reputation points
2026-10-26T21:57:02.6166667+00:00

I am setting up a development database for a small internal business application using an Azure Free Trial subscription.

Creating an Azure Database for PostgreSQL Flexible Server in West US 3 fails with:

SkuNotAvailable: Specified SKU is not supported in this region. Please choose a different SKU.

Configuration:

  • PostgreSQL version: 17

Compute tier: Burstable

SKU: Standard_B1ms, 1 vCore, 2 GiB RAM

Storage: 32 GiB

Availability zone: No preference

High availability: Disabled

Backup retention: 7 days

Troubleshooting completed:

Confirmed that Microsoft.DBforPostgreSQL is registered in my subscription.

Ran az postgres flexible-server list-skus --location westus3 --output table. The output includes Standard_B1ms.

Confirmed that the Azure portal also lists B1ms as a selectable size.

Checked West US 2, but the portal says my subscription is not allowed to provision PostgreSQL servers there.

My application hosting is already in West US 3, so I would prefer to keep the database in that region.

How can I determine whether this is temporary capacity unavailability, a subscription offer restriction, or another configuration issue? Is there a way to verify which region and compute size my subscription can actually provision before attempting another deployment?

I would appreciate guidance on resolving this while keeping the database suitable and affordable for development.I am setting up a development database for a small internal business application using an Azure Free Trial subscription.

Creating an Azure Database for PostgreSQL Flexible Server in West US 3 fails with:

SkuNotAvailable: Specified SKU is not supported in this region. Please choose a different SKU.

Configuration:

PostgreSQL version: 17

Compute tier: Burstable

SKU: Standard_B1ms, 1 vCore, 2 GiB RAM

Storage: 32 GiB

Availability zone: No preference

High availability: Disabled

Backup retention: 7 days

Troubleshooting completed:

Confirmed that Microsoft.DBforPostgreSQL is registered in my subscription.

Ran az postgres flexible-server list-skus --location westus3 --output table. The output includes Standard_B1ms.

Confirmed that the Azure portal also lists B1ms as a selectable size.

Checked West US 2, but the portal says my subscription is not allowed to provision PostgreSQL servers there.

My application hosting is already in West US 3, so I would prefer to keep the database in that region.

How can I determine whether this is temporary capacity unavailability, a subscription offer restriction, or another configuration issue? Is there a way to verify which region and compute size my subscription can actually provision before attempting another deployment?

I would appreciate guidance on resolving this while keeping the database suitable and affordable for development.

Azure Database for PostgreSQL
0 comments No comments

1 answer

Sort by: Most helpful
  1. AI answer

    2026-10-26T21:58:07.6466667+00:00

    Select another Burstable SKU in West US 3, or submit a PostgreSQL Flexible Server region-access request if Standard_B1ms is required; the documented response to this exact SkuNotAvailable error is to use a different SKU because the requested SKU can be unsupported or temporarily unavailable in that region.^1^

    What the existing results mean

    • az postgres flexible-server list-skus --location westus3 lists SKUs associated with the region, but it does not establish that capacity is currently allocatable to this subscription. The command is documented only as listing available SKUs in a region.^2^
    • West US 3 supports PostgreSQL Flexible Server and Burstable compute generally, so this is not evidence that the service or Burstable tier is categorically unsupported there.^3^
    • Quota and capacity are different:
      • Quota is the subscription’s allowed resource limit.
      • Capacity is the infrastructure currently available for the exact region, service, and SKU.
      A valid catalog entry and sufficient quota can therefore coexist with a capacity failure.^4^

    Because the provider is already registered and the error is SkuNotAvailable, re-registering it is not the next step. A quota failure would normally report an exceeded-core limit rather than this SKU error.^1^

    Check subscription quota separately

    The PostgreSQL PowerShell module exposes subscription- and location-specific quota usage. Run:

    Get-AzPostgreSqlFlexibleServerQuotaUsage `
      -LocationName westus3 |
      Select-Object NameValue, Limit, CurrentValue
    

    Inspect cores and the Burstable/BS-family entry. If the remaining limit is below the requested vCore count, submit a quota request. This command verifies quota only; it cannot prove that B1ms capacity is available at deployment time.^5^

    If quota is sufficient, try the least expensive adjacent Burstable SKU presented for West US 3 by the portal or CLI, retaining:

    • Availability zone: No preference
    • High availability: Disabled
    • Storage: 32 GiB
    • PostgreSQL: 17

    No-preference placement already avoids pinning the deployment to a potentially constrained zone. A successful adjacent-SKU deployment indicates that the constraint is specific to B1ms rather than the overall PostgreSQL configuration.

    There is no conclusive public “available now” check

    Azure’s public product/region table is informational rather than a live capacity feed.^6^ ARM preflight validation can identify some provider, quota, capacity, policy, and schema problems before creation, but it is best-effort and does not catch every deployment-time failure.^7^

    Consequently, neither list-skus nor preflight can reliably certify that this exact PostgreSQL SKU is allocatable. The actual create request—or Microsoft support’s backend capacity check—is authoritative for that moment and subscription.

    Request access or capacity review

    If B1ms is important for cost reasons:

    1. Azure portal → Help + support → Create a support request.
    2. Set Issue type to Service and subscription limits (quotas).
    3. Select the Free Trial subscription.
    4. Set Quota type to Azure Database for PostgreSQL flexible server.
    5. Under request details, request Region access for West US 3, specifying:
      • Standard_B1ms
      • 1 vCore
      • PostgreSQL 17
      • The full SkuNotAvailable message
    6. Include the failed deployment’s correlation ID. Deployment history records errors and correlation IDs that support can use to trace the request.^8^

    The PostgreSQL troubleshooting guidance specifically recommends a Region access request for unresolved provisioning issues, while approval can depend on regional capacity.^1^ The documented request workflow asks for the location, SKU series, and requested quota.^9^

    For a small development workload, Burstable remains the appropriate low-cost tier; it is intended for development and low-concurrency workloads without continuous compute demand.^3^


    References

    1. Resolve capacity errors for Azure Database for PostgreSQL flexible server
    2. az postgres flexible-server | Microsoft Learn
    3. What is Azure Database for PostgreSQL flexible server?
    4. How to design for capacity resilience
    5. Get-AzPostgreSqlFlexibleServerQuotaUsage-Description
    6. Product Availability by Region - azure.microsoft.com
    7. Preflight: Server validation before deployment
    8. View deployment history with Azure Resource Manager
    9. Request quota increases for Azure Database for PostgreSQL flexible server
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.