It is easy to choose a larger database size during deployment and notice the cost only after the application is already running. This guide shows how to scale Azure PostgreSQL Flexible Server from Standard_B2s to Standard_B1ms without rebuilding the application or changing the database endpoint.
The change is limited to compute. Azure restarts the database server when the compute tier or size changes, so plan a short interruption: new connections can fail and uncommitted transactions can be rolled back. The Container Apps workloads remain deployed, but an API that depends on PostgreSQL may briefly return errors until the database is ready again.
Table of contents
Before you scale Azure PostgreSQL
This procedure applies to Azure Database for PostgreSQL Flexible Server. The example resource names are intentionally generic:
- Resource group:
rg-example-prod - Server:
psql-example-prod - Region:
northeurope - Current SKU:
Standard_B2s - Target SKU:
Standard_B1ms
You need Azure CLI access to the correct subscription and permission to update the server. Run the change during a quiet period, confirm that normal automated backups and recovery settings are healthy, and pause schema migrations or batch jobs during the maintenance window.
Important: Do not add a storage-size change to this operation. Azure Flexible Server storage can be increased, but it cannot be scaled back down. This guide changes compute only.
1. Confirm the Azure account and subscription
A safe change begins by proving which subscription the CLI will modify:
az account show --query "{subscription:name,id:id,tenant:tenantId}" -o table
If it is not the intended subscription, switch explicitly:
az account set --subscription "<subscription-id-or-name>"
Repeat az account show before proceeding. This extra check is faster than recovering from a correct command run against the wrong environment.
2. Read the current PostgreSQL SKU and state
Use a focused query to confirm both the current size and operational state:
az postgres flexible-server show --resource-group rg-example-prod --name psql-example-prod --query "{sku:sku.name,tier:sku.tier,state:state,location:location}" -o yaml
Expected output before the change resembles:
location: northeurope
sku: Standard_B2s
state: Ready
tier: Burstable
Do not continue if the server is already updating, restarting or otherwise unhealthy. Also check the Azure portal for active alerts or a service-health event in the region. The official Azure CLI reference documents the show, list-skus and update commands used here.
3. Establish a small baseline
Before you scale Azure PostgreSQL, record enough evidence to decide whether B1ms is appropriate and to detect a regression afterward. Review at least:
- CPU percentage during the normal busy period.
- Memory pressure and storage I/O behavior.
- Active and peak connection counts.
- API latency and database-related application errors.
- Background jobs or migrations that create short bursts.
From PostgreSQL, two simple checks are:
SHOW max_connections;
SELECT count(*) AS current_connections
FROM pg_stat_activity;
One application replica under normal load may fit comfortably, while three autoscaled replicas with large connection pools may not. Check the configured pool size in the application as well as the instantaneous database count. A smaller compute SKU should be a measured fit, not merely the cheapest selectable option.
4. Confirm that B1ms is available in the region
Available SKUs can differ by region and subscription. Query the intended location rather than assuming that the example target exists everywhere:
az postgres flexible-server list-skus --location northeurope -o table
Find Standard_B1ms in the Burstable tier. If it is not listed, stop and choose from the sizes actually offered for that server and region. Also confirm that the memory and connection profile is appropriate for the workload.
5. Prepare for the restart
According to Microsoft’s compute scaling documentation, a compute change restarts the server and causes service interruption. The broader scaling concepts guidance notes that new connections are unavailable during the operation and uncommitted transactions are rolled back.
Before the maintenance window:
- Notify anyone actively using the application.
- Stop long-running imports, migrations and manual transactions.
- Confirm application connection retries and reasonable timeouts.
- Open the API health check, application logs and database metrics.
- Record the current SKU so rollback is one command away.
Azure offers scaling behavior designed to reduce downtime in supported scenarios, but the safest operational assumption is still that connections will be interrupted. Do not promise a zero-downtime change.
6. Change only the compute SKU
Run the update command without --yes. The Azure CLI will show the restart warning and require explicit confirmation:
az postgres flexible-server update --resource-group rg-example-prod --name psql-example-prod --tier Burstable --sku-name Standard_B1ms
Read the target resource and SKU one more time in the prompt, then confirm. This command does not redeploy the Container App, change the PostgreSQL hostname, recreate the database or modify private networking. Existing application configuration should remain valid. The interruption comes from terminated database connections during the server restart.
If the command returns an availability or capacity error, do not repeatedly force it. Re-run the regional SKU query and review the server’s current state and Azure activity log.
7. Wait for the server to return to Ready
Poll the authoritative server state rather than relying only on the command completion message:
az postgres flexible-server show --resource-group rg-example-prod --name psql-example-prod --query "{sku:sku.name,tier:sku.tier,state:state}" -o yaml
Continue only when the output shows:
sku: Standard_B1ms
state: Ready
tier: Burstable
A normal restart may take roughly a minute or several minutes depending on the operation and environment. Treat that as an observation range, not a guarantee. If the server does not return to Ready, inspect the Azure activity log and support status before changing anything else.
8. Verify the application and keep rollback ready
After you scale Azure PostgreSQL, perform checks from the application side as well as from Azure:
- Call the API health or readiness endpoint.
- Run one read and one harmless write through the normal application path.
- Inspect application logs for authentication, DNS, timeout and pool-exhaustion errors.
- Repeat the active-connection query.
- Watch CPU, memory and latency during the next representative workload period.
If B1ms is too small, return to B2s with the same controlled procedure:
az postgres flexible-server update --resource-group rg-example-prod --name psql-example-prod --tier Burstable --sku-name Standard_B2s
Rollback also causes a restart, so it is not instantaneous. That is why the baseline and maintenance window matter.
Observed cost result from the original environment
In the environment that motivated this guide, the portal showed the accidental B2s selection at roughly $53 per month. A later billing export recorded $5.45 for 13 days on B1ms—about $0.42 per day, or approximately $12.60 over 30 days at that observed rate.
This is historical evidence from North Europe in August 2026, not a universal price quote. Azure pricing varies by region, currency, reservation, billing agreement and date. Use the Azure pricing calculator and the actual invoice for your environment.
Frequently asked questions
Will changing from B2s to B1ms change the database endpoint?
No. When you change only the compute tier and SKU of the same Flexible Server resource, the server name, database data and networking configuration remain attached to that resource. Applications can still experience failed connections while the server restarts.
Can I scale Azure PostgreSQL without any interruption?
Plan for an interruption. Microsoft documents a restart for vCore and tier changes. Supported near-zero-downtime scaling can shorten the impact in some cases, but applications should still use connection retries and the change should still be scheduled.
Should I reduce storage at the same time?
No. Flexible Server storage cannot be scaled down after it has been provisioned. Keep the operation limited to --tier and --sku-name.
Is B1ms always the right production size?
No. It was appropriate for a small, lightly loaded service after checking its connection and resource profile. Workloads with sustained CPU, memory pressure, high concurrency or strict latency requirements may need a larger or non-burstable tier.
Conclusion
The safest way to scale Azure PostgreSQL is to make one reversible change at a time: verify the subscription, capture the current state, confirm regional availability, plan for the restart, update only the compute SKU and test from the application path. The CLI command is short; the checks around it are what make the operation reliable.