How to Reduce Azure SQL Costs: A Practical Checklist (2026)
Azure SQL is easy to start and easy to overspend on. Most teams size their databases once, during migration, and never look again, so they keep paying for capacity they do not use. The good news is that the biggest savings usually come from a handful of changes that take hours, not weeks.
This checklist walks through those changes in the order I would apply them: measure first, then fix licensing and commitments, then architecture, then queries.
1. Right-size from real usage, not from the old server
The most common mistake is sizing Azure to match the on-premises server's hardware. Old servers were bought for peak load plus growth, and often sat at 10 to 20 percent CPU.
- Check at least two to four weeks of CPU, data IO, log IO and memory usage.
- In Azure SQL Database,
sys.dm_db_resource_statsshows usage for roughly the last hour at 15-second intervals, andsys.resource_statsin themasterdatabase keeps longer history. - If average usage stays low and peaks are short, scale down one tier and watch for a week.
-- Average and peak usage over the last hour (Azure SQL Database)
SELECT
AVG(avg_cpu_percent) AS avg_cpu,
MAX(avg_cpu_percent) AS max_cpu,
AVG(avg_data_io_percent) AS avg_data_io,
AVG(avg_log_write_percent) AS avg_log_write
FROM sys.dm_db_resource_stats;Scaling an Azure SQL Database up or down is an online operation that usually completes in minutes, so it is low risk to try a smaller size.
2. Use Azure Hybrid Benefit
If your organisation already owns SQL Server licences with Software Assurance (or qualifying subscriptions), Azure Hybrid Benefit lets you apply them in the vCore purchasing model so you stop paying for the SQL licence again. For many workloads this is the single largest saving. It does not apply to the DTU model or to serverless compute, so check which model each database uses.
3. Buy reserved capacity for steady workloads
Production databases that run 24x7 at a predictable size are the most expensive thing to run on pay-as-you-go. Reserved capacity commits you to a vCore amount for one or three years in exchange for a lower rate, and it can be combined with Azure Hybrid Benefit. Reserve only the baseline you are confident about; burst above it on pay-as-you-go.
4. Use serverless for dev, test and intermittent workloads
The General Purpose serverless tier bills compute per second and can auto-pause when idle, leaving only storage charges. It is ideal for development and test databases and for apps used mainly in business hours.
Watch for anything that keeps the database awake: open SSMS windows, connection pools, monitoring probes and scheduled jobs. A serverless database that never pauses can cost more than a small provisioned one.
5. Put small databases in an elastic pool
If you run many small databases with uneven load, such as one per customer, an elastic pool lets them share a fixed amount of compute. Because their peaks rarely happen at the same time, the pool can be much cheaper than sizing each database for its own peak.
6. Trim backup, replica and storage costs
- Backup retention: keep long-term retention only where policy requires it, and review whether geo-redundant backup storage is needed for non-production databases.
- Replicas: geo-replicas and failover groups are billed as full databases. Make sure each one is still required.
- Allocated space: after large deletes, check allocated versus used space before paying for a bigger maximum size.
7. Tune the top queries before buying a bigger tier
A missing index or one bad query can push a database two tiers higher than it needs. Before scaling up, open Query Store, sort by total CPU or duration, and fix the top five queries. That often frees enough headroom to scale down instead.
-- Top 5 queries by total CPU time (Query Store)
SELECT TOP (5)
q.query_id,
SUM(rs.count_executions) AS executions,
SUM(rs.avg_cpu_time * rs.count_executions) / 1000 AS total_cpu_ms,
MAX(qt.query_sql_text) AS query_text
FROM sys.query_store_runtime_stats rs
JOIN sys.query_store_plan p ON rs.plan_id = p.plan_id
JOIN sys.query_store_query q ON p.query_id = q.query_id
JOIN sys.query_store_query_text qt ON q.query_text_id = qt.query_text_id
GROUP BY q.query_id
ORDER BY total_cpu_ms DESC;8. Set budgets, alerts and review Azure Advisor
Savings drift back without monitoring. In Cost Management, create a budget per subscription or resource group with alerts at 80 and 100 percent. Review Azure Advisor cost recommendations monthly; it flags idle and under-used databases for you.
Quick checklist
| Action | Effort | Typical impact |
|---|---|---|
| Right-size from real usage | Low | High |
| Azure Hybrid Benefit | Low | High (if licences exist) |
| Reserved capacity | Low | High for 24x7 workloads |
| Serverless for dev/test | Low | Medium |
| Elastic pools | Medium | Medium to high |
| Backup and replica review | Low | Low to medium |
| Query tuning | Medium | Medium to high |
| Budgets and alerts | Low | Prevents drift |
Final thoughts
Start with measurement, because every other decision depends on it. Then apply licensing and commitment discounts to what you truly need, and only then look at architecture and queries. Prices and offers change, so confirm the numbers for your region in the Azure Pricing Calculator before committing.
Related reading:
Comments
Post a Comment