Skip to content
Cloud Efficiency Hub

Suboptimal Use of Serverless Compute for Azure SQL Database

The short version

Serverless is attractive for variable or idle workloads, but it can become more expensive than Provisioned compute when database activity is high for long portions of the day.

Benjamin van der Maas

Manager, Cloud FinOps @ Johnson & Johnson

Azure service
Azure SQL
Category
Databases
Reference
CER-0264
Type
Suboptimal Tier or SKU

Explanation

Why the waste happens and who it affects.

As active time increases, per-second compute accumulation approaches - or exceeds - the fixed monthly cost of a Provisioned tier. This inefficiency arises when teams adopt Serverless as a default without assessing workload patterns. Databases with steady demand, predictable traffic, or long active periods often operate more cost-effectively on Provisioned compute. The economic break-even point depends on workload activity, and when that threshold is consistently exceeded, Provisioned becomes the more efficient option.

Billing model

The pricing dimensions that drive this cost.

Serverless compute accrues cost based on active vCore-seconds, scaling with workload intensity. Provisioned compute charges a fixed hourly rate regardless of activity. For consistently active workloads, Serverless may produce higher cumulative cost than a fixed Provisioned configuration.

How to detect

4 checks to find it in your estate.

  • Review whether workload activity remains high for most hours of the day
  • Assess whether cumulative monthly active time exceeds the conceptual break-even range for Serverless
  • Evaluate workloads with steady or predictable utilization patterns that do not benefit from auto-pause
  • Identify production databases where performance consistency is prioritized and continuous compute is required

How to fix

4 ways to remove the waste.

  • Move consistently active workloads from Serverless to the Provisioned compute tier to reduce cost
  • Use workload profiling to validate that utilization patterns justify a fixed compute allocation
  • Periodically reassess compute tier selection as application behavior evolves
  • Ensure the chosen vCore configuration provides appropriate performance headroom after migration

Documentation

Vendor references for pricing and configuration.