Unable to upgrade Azure Database for PostgreSQL Flexible major version

Question

I have a Azure Database for PostgreSQL Flexible server that I am attempting to upgrade the major version on in the US East region.

I consistently get the error message: "The value of the 'Version' should be in: []. Verify that the specified parameter value is correct."

After making sure all the prerequisites are met, i still get that error message and the only thing I can think of that might be hindering it is the SKU of the compute. When i try to scale the instance, i have no options to change the compute size.

How can I tell which prerequisite is preventing the major version upgrade? If it is the compute size, how can I get the quota to allow "scaling" to a valid sku that can be upgraded from.

Answer 1

Hi Shawn Silva,
Thanks for the quick reply with those details that really helps narrow it down. Upgrading from PostgreSQL 11 to 15 on a Standard_E2s_v3 SKU in East US is supported in principle (no read replicas/slots or UUID-OSSP issues blocking you), but the empty "Version should be in: []" list and no compute scaling options point to two common gotchas: SCRAM authentication not enabled (PG11 defaults to MD5, which blocks upgrades) and v3-series SKU capacity gating in the region.

First, enable SCRAM (required pre-req): Connect via psql or the portal Query tool and run:

text
ALTER SYSTEM SET password_encryption = 'scram-sha-256';
SELECT pg_reload_conf();
ALTER USER yourusername WITH PASSWORD 'newstrongpassword';  -- Do this for *all* users/roles

Verify with:

SELECT rolname, passwd FROM pg_authid WHERE passwd !~ '^SCRAM-SHA-256$'; (should be empty). Restart the server after.

Then check/tackle SKU eligibility:

Run az postgres flexible-server list-skus --location eastus -o table | grep -i 'E2s\|15' in CLI. If no PG15 targets show for v3 (or v5 equivalents), that's the quota/capacity restriction—portal quotas might not reflect SKU-family limits.

Try scaling to a v5 equivalent first (e.g., Standard_E2s_v5) in portal > Compute + storage, then retry upgrade. If still no options: Go to Subscription > Usage + quotas > Filter "PostgreSQL Flexible Server" > Request increase for "vCore" or "Standard_E" family in East US.

Test this on a PITR restore to a new server name first (upgrades are irreversible). If CLI upgrade works directly (az postgres flexible-server upgrade --resource-group <rg> --name <server> --version 15), great—otherwise reply with that list-skus output + server/resource group name, and we'll dig into backend eligibility or escalate.

Let me know if you have further queries.

Answer 2

Hi Shawn Silva,
Thanks for confirming that SCRAM is already enabled and for testing the PITR upgrade that rules out the usual server‑side prerequisites and points to a regional/offer issue.

Since az postgres flexible-server list-skus --location eastus returns no results and you also have no scaling options in the Compute + storage blade, your subscription currently has no PostgreSQL Flexible Server SKUs exposed in East US. In this state the major‑version upgrade API gets an empty list of allowed target versions and returns Version should be in: [], and scale operations have nothing to offer.

This is not something you can fix by changing parameters on the server; it is a region access / capacity gating behavior for that subscription in East US. The two practical next steps are:

Either deploy/upgrade in another region where list-skus shows SKUs for your subscription, or

Request enablement of PostgreSQL Flexible Server SKUs for East US on this subscription via a Service and subscription limits (quotas) request (Quota type: Azure Database for PostgreSQL Flexible Server, Region: East US, with a short note that list-skus is empty and upgrades and scaling are blocked).​

Once SKUs are enabled in East US, list-skus will start returning values, the Compute + storage blade will show scale options again, and the major version upgrade will surface valid target versions instead of the empty [] list.