Azure SQL Server database costs climbing unexpectedly

Question

Azure SQL Server database costs climbing unexpectedly

John Ho 0

We are just starting out experimenting with Azure development and we are seeing our costs climbing unexpectedly once we created the cheapest Azure SQL Server database we could create.

0 comments

2 answers

Your answer

Answer 1

Exactly what tier did you create? You find that in the Pricing Tier field on the home page for the database. For instance:

User's image

When you say price run away unexpectedly, I get the impression that you have selected the Serverless option. Serverless can be very cheap; I have a few of these. The key is: I don't access them very often. A Serverless database is rolled out when it has not been in use for a while, and then you only pay for storage. But once it is loaded, you pay more than for a regular General Purpose (which is more expensive than my S1). And note that what matters is if it is loaded. If it stays idle, but there is a query every ten minutes that keeps it loaded, that will cost as much if you are running heavy queries all the time.

Serverless is great for test/dev databases you use occasionally, but there are many other things it is not good for. Microsoft is a little bit to eager to offer this option.

Answer 2

Identify the exact billing meter in Cost Analysis first, then change the database’s compute configuration based on whether the charge is provisioned compute, serverless compute, storage, or backups.

1. Identify what is accumulating

In the Azure portal, open the SQL database.
On Overview, select its Resource group.
Select Cost analysis.
Set the chart grouping to Service name.
Select Add filter → choose Service name → Azure SQL Database.
Change the grouping to Meter or Resource if available, and inspect whether the increasing charge is:
- Compute
- Compute (serverless)
- Data storage
- Backup storage
- Another resource in the same resource group

Cost Analysis requires at least read access to the relevant Azure account. Azure SQL can bill compute, storage, backup storage, licenses, and applicable replicas or add-ons separately.^1^

The logical SQL server is the management container; use the resource-level and meter-level breakdown to establish which deployed resource is generating the charge rather than assuming the server name itself is responsible.

2. Select a suitable development configuration

Open the database and select Settings → Compute + storage or Configure. The available controls depend on its current purchasing model.

If the free database offer is enabled

Open the compute configuration, turn off the free database offer, select the DTU purchasing model, choose the Basic service tier, and select Apply. This produces a more predictable always-on development cost when the database fits Basic’s capacity.^2^

Before applying the change, review the displayed monthly estimate and ensure the tier meets the database’s storage and performance requirements.

If usage is intermittent: General Purpose serverless

Open SQL database → Settings → Compute + storage.
Select the vCore purchasing model.
Select General Purpose and Serverless compute.
Set the smallest suitable minimum vCores and maximum vCores.
Enable auto-pause and select an auto-pause delay appropriate for development.
Review the estimated cost and select Apply.

Serverless is intended for intermittent, unpredictable workloads. General Purpose supports an auto-pause delay starting at 15 minutes; its default is 60 minutes. A connection or other activity automatically resumes the database.^3^

Serverless does not mean no charge whenever queries stop:

Until the database actually pauses, minimum configured compute and memory remain billable.
When paused, compute billing becomes zero.
Storage continues to be charged while paused.^4^

A longer auto-pause delay can therefore create several hours of compute charges after development activity ends.

3. If a serverless database never pauses

Check this only if Cost Analysis shows serverless compute and the database remains online beyond its configured delay.

Open sessions prevent auto-pause. The following features can also prevent it:

Active geo-replication
Failover groups
Long-term backup retention
DNS aliases
Elastic jobs when the database is the job database

Microsoft documents sys.dm_exec_sessions as the view to check for open application or user sessions.^5^

Also check development tools, health probes, APIs, monitoring jobs, and connection pools that might reconnect periodically. Each new connection to a paused database resumes it.

4. Prevent another unexpected increase

In Cost Management + Billing, create a budget scoped to the subscription or resource group and configure threshold alerts. Budgets notify you; they do not automatically stop resources. Filters can narrow the budget to a particular service or resource.^1^

If the database is no longer required, deletion stops future database resource charges. Deletion can permanently remove development data, so first confirm the database is unnecessary and create or verify a recoverable backup/export.

If the meter-level breakdown still does not explain the increase, open Help + support → Create a support request, select Billing, and include the subscription, database resource, dates, and Cost Analysis meter details. Azure billing support requests are available without a paid technical support plan.^6^

References