Sql Server Billing is very incorrect

Hi @Dejan Popovic

For Azure SQL Database serverless, the bill is often not just “max vCore rate × max size,” and the portal’s forecast can look surprising until you break down which meter(s) are driving it.

Why the forecast can be much higher than the numbers you’re seeing

For serverless Azure SQL Database, the total bill is the sum of:

• Compute (billed per second based on actual usage patterns and the serverless billing rules)
• Storage (billed monthly based on allocated/storage size characteristics of the tier)

Key points from Microsoft’s billing model:

• Compute is billed per second using the maximum of CPU used vs. memory used each second.
• If CPU/memory usage is below the minimum provisioned amount while the database is online, you can still be billed at the minimum.
• Memory is normalized into vCores for billing comparison (so memory usage can drive compute cost even when CPU looks low).

So even if your “Compute cost / vCore second” looks tiny, the database may be billing many vCore-seconds over the month depending on your workload and the minimums.

Also, the overall “estimated forecast” can include more than just compute/storage you initially focused on (for example, other SQL-related meters show up in Cost Analysis—depending on what’s enabled/configured).

What to do to confirm what’s driving the forecast

Microsoft recommends using Cost Management → Cost analysis to identify the exact meters/resources behind the estimate:

1. Go to the resource group containing your Azure SQL Database
2. Select Cost analysis
3. View Accumulated costs
4. (Optional but helpful) Set the chart to Service name
5. Add a filter for Azure SQL Database
6. Then use filters/grouping to find what’s driving the difference:

• Filter by “Meter category” / “Service name” to see if it’s Compute vs Storage vs other SQL-related meters
  • If you can, group by Resource to see which specific resource/meter contributes most

This will tell you whether the forecast is being driven by compute billed minutes/seconds, storage, or something else.

How to sanity-check pricing for serverless

For serverless SQL DB, cost estimation depends on:

• serverless billing behavior (CPU vs memory, minimums)
• your workload pattern (active vs idle; auto-pause behavior)
• configured vCore min/max range
• storage characteristics

If you find the answer helpful, please click "upvote" and accept it. This will help others in the community with similar questions easily find the solution.

Forecasts for Serverless are inherently inaccurate, because it all depends on how you use the service. First you need to understand that when Serverless is paused it is rolled out and exists only disk, and in this state you pay only for storage. Once someone connects to it, it is rolled in and mounted on a server, and now you start to pay for compute.

Serverless is great for a database that you only use occasionally, like an hour a day and it is rolled out most of the day. It's a really bad option for a database that is always active, because the price for compute is higher for a provisioned general-purpose database. One risk with serverless is that you think you are not using it, but there is something that pings it every five minutes which prevents it from being paused. Keep in mind, it is the fact that it is mounted you pay for, not the actual CPU time you consume.

If you want something which is really budget-friendly, I recommend an S0 or S1 (i.e. a DTU-based model). They are really cheap. And, no, they are overly powerful, but if you are only learning and playing, they can still serve you well.

But going back to Serverless, it can be a great choice, if you understand the service. If you don't, it will be expensive.