How to review an Azure underused sql database
An Azure SQL database is a downsizing or consolidation candidate when representative compute, storage, IO, concurrency, and latency evidence suggests a lower service objective can meet the workload with safe headroom.
Test a compatible SQL service objectiveWho reviews this signal?
- Accountable owner
- Database + application owner
- Review cadence
- Monthly
Check observation dates and read-only scope. Your team approves and implements changes outside Costframe.
How this finding happens
- →The database is provisioned for a forecast peak that never arrives.
- →Reporting or application traffic moves elsewhere but the tier remains.
- →Development and test copies inherit production sizing.
Collected evidence and verification limits
Checked when available
- ✓Service tier, compute model, hardware generation, zone/replica configuration, storage, and licensing
- ✓DTU or vCore-related utilization, CPU, data/log IO, workers/sessions, storage and latency signals
- ✓Representative peak and business-cycle window
- ✓Compatible target tier and net price basis
Not always verifiable
- —Averages conceal batch, month-end, and concurrency peaks.
- —Serverless, provisioned, elastic-pool, Hyperscale, and DTU/vCore models require different reasoning.
- —Query performance, HA, backup retention, and licensing can dominate the decision.
Missing or stale evidence is a limitation, not a passed check.
Why this finding might be wrong
These conditions lower confidence or require manual owner review before action.
- Month-end or overnight batch workload
- Database retained for failover, audit, or regulatory access
- Latency-sensitive service with deliberate headroom
- Temporary low demand before a known launch
Plan the change and recovery path.
- Review a window covering peaks, query workload, IO, concurrency, storage growth, HA and backup requirements.
- Select a compatible target rather than applying a universal percentage threshold.
- Benchmark or stage the change, define rollback signals, and schedule with the database owner.
- Observe throttling, latency, errors, CPU/IO, and business transactions after change.
Rollback / recovery
Restore the prior service objective if workload or business thresholds breach. Preserve configuration and understand resize duration and availability implications in advance.
How savings are calculated
Estimated net monthly saving = current net database cost − compatible target net cost, including material license, replica, backup, and pool effects.
Do not quote a quantified saving when the billing scope, pricing basis or required workload evidence is incomplete or stale. Treat a modeled amount as estimated until suitable billed outcomes support it.
Check the billed outcome
Net cost decreases and query/application SLOs remain within agreed limits.
Test a compatible SQL service objective
Ask the database owner for peak query latency, workers, sessions, data and log IO, and month-end demand. Compare the target's compute model, HA and backup requirements, then define a staged test and restoration threshold. Do not reuse a VM CPU rule for SQL.
Review commitments after sizingIf the owner cannot resolve a dependency or recovery requirement, keep the candidate in review rather than treating it as approved.