By Cloudledger · Updated
The purchasing model shapes the bill
Azure SQL Database offers vCore and DTU-based models, along with options such as serverless and elastic pools. Each bills differently, so two databases with similar workloads can have very different cost profiles. Identify the model in use before comparing databases or estimating a change.
Compute, storage and backup are separate lines
Compute is usually the largest component, but allocated storage and backup retention also bill. Long-term retention can accumulate quietly. Group by meter for a single database to see the split before deciding what to change.
- Identify the purchasing model and tier for each database.
- Group costs by meter for a complete period.
- Review allocated storage against actual use.
- Check backup retention against recovery requirements.
Look for idle and oversized databases
Non-production databases often run at provisioned capacity around the clock. Serverless or elastic pools can suit intermittent workloads, while a smaller tier may fit a steady low-usage database. Validate against performance metrics and business requirements; a database that fails at month-end is not optimized.
Reservations apply to some database compute
Reserved capacity can reduce the rate for eligible vCore-based compute. The commitment considerations are the same as for other reservations: term, scope, eligibility and the risk of committing to a shape that changes. Confirm eligibility for your specific configuration.
Change carefully and verify
Tier and model changes can affect performance, availability and failover behaviour. Test with a representative workload where possible, agree a maintenance window and keep a rollback path. Then confirm the effect on both performance and the next complete billing period.