Submit feedback on
Suboptimal Use of Serverless Compute for Azure SQL Database
We've received your feedback.
Thanks for reaching out!
Oops! Something went wrong while submitting the form.
Close
Suboptimal Use of Serverless Compute for Azure SQL Database
Benjamin van der Maas
CER:
Azure-Databases-6502
Service Category
Databases
Cloud Provider
Azure
Service Name
Azure SQL
Inefficiency Type
Incorrect Compute Tier Selection
Explanation

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. 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.

Relevant Billing Model

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.

Detection
  • 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
Remediation
  • 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
Relevant Documentation
Submit Feedback