Review Azure SQL capacity before downsizing
On this page
Downsize only after checking all relevant resource metrics across representative peaks, because CPU headroom alone can hide I/O, worker, session or storage limits and cause a performance hit.
What you need first
- Tool
- Azure Monitor metrics explorer is the Azure portal tool for charting resource measurements. Open the database or elastic pool, then select Monitoring > Metrics in the resource menu.
- Access
- If you cannot view the resource, ask an authorized Azure SQL colleague for read-only metric charts and current configuration details for the named database or elastic pool.
- If you do not use that tool
- Give the colleague the database or pool name and a period covering business peaks and scheduled jobs. Request the completed checklist, charts with units and aggregations, current purchasing model, compute size and data size limit.
Why this is worth a look
Skipping this review can turn apparent CPU headroom into a performance problem or an incomplete cost comparison. DTU compute is billed by allocated DTUs, while provisioned vCore compute reflects provisioned capacity. For data storage, Azure charges against the selected maximum database or pool size. DTU percentage is the highest of CPU, data I/O and log I/O at each point, so average CPU cannot prove spare capacity.
Run this check
CHECKLISTUse Azure Monitor metrics explorer for one database or elastic pool. Record the time window, units and aggregations. Review charts and configuration only, and leave settings unchanged.
[ ] Name one provisioned database or elastic pool and its workload owner.
[ ] Obtain the purchasing model, service tier, compute size and configured data size limit from an authorized Azure SQL colleague.
[ ] Open the resource in the Azure portal. Select Monitoring > Metrics.
[ ] Set a time range covering normal business peaks and scheduled processing, including month-end if relevant. Record the start, end and granularity.
[ ] Chart CPU percentage (cpu_percent), Data IO percentage (physical_data_read_percent) and Log IO percentage (log_write_percent). Record percent units and compare Average and Maximum where supported.
[ ] Inspect workers_percent and Sessions count where available and relevant. Record displayed units, aggregations and peaks. Do not replace an unavailable metric with zero.
[ ] For DTU resources, chart DTU percentage (dtu_consumption_percent), in percent, including Maximum where supported.
[ ] Chart storage_percent, in percent toward the configured data size limit. Record that limit beside the chart.
[ ] Ask the workload owner whether the period includes all important peaks. Record missing events.
[ ] Mark the resource as a review candidate only when relevant metrics show sustained headroom. If coverage is incomplete, record: wait for more evidence.
[ ] Record a proposed target size and compare its supported resource limits with workload needs. Request a workload test before any change.
[ ] If the comparison uses Azure Hybrid Benefit, ask the licensing owner to confirm eligible Software Assurance-enabled SQL Server licenses. The benefit applies only to provisioned vCore Azure SQL Database, not DTU or serverless.
[ ] Leave resource settings unchanged.How to confirm it
- 01
Match the review to billing scope
Choose one database or elastic pool. For vCore resources, compute, I/O, and data and log storage are charged per database for single databases and per pool for elastic pools; backup storage is always charged per database. Keep these scopes separate in the comparison.
- 02
Cover representative workload peaks
Ask the workload owner which business hours and scheduled jobs the charts must cover. Run the checklist for that period, including month-end when relevant. Wait if a known peak is missing instead of treating a quiet window as downsizing evidence.
- 03
Separate candidates from approved changes
Compare recurring peaks across all relevant metrics. Shortlist resources with sustained headroom, but do not use a universal utilization threshold. Treat missing or inapplicable metrics as a reason to investigate, not as proof of spare capacity.
- 04
Validate the target and license basis
Compare the proposed size with workload needs before approving a change. DTU uses bundled compute, storage and I/O, while vCore lets you choose compute and storage independently. Ask the licensing owner to confirm entitlement before including Azure Hybrid Benefit.
Before making changes
Assume the selected period represents future workload only after the workload owner confirms it. Percentages measure consumption against current limits, not the capacity a smaller size will provide. Metric availability varies by resource type. A Business Critical tier change also changes replica and local SSD characteristics, so spare CPU alone does not justify it.