# Azure SQL Right-sizing > ZopNight flags an online Azure SQL database when 30-day average DTU consumption sits under 10%, the peak never touched the 80% ceiling, and a concrete one-step-down service objective exists (S3 to S2, for instance). Savings come from the real DTU-tier rate delta; vCore and bottom-rung databases abstain. Source: https://zop.dev/integrations/azure/recommendations/azure-sql-right-sizing Updated: 2026-08-19 --- ## DTU tiers make overprovisioning invisible A DTU-model database bills its service objective flat: an S3 costs the same at 2% consumption as at 90%. Because scaling is a slider someone set once, databases routinely run years above their need. The rule reads the DTU-consumption series over 30 days; an average under 10% marks the database as provisioned for a workload it does not have. Only databases in an online state are considered; restoring, offline, and paused databases are skipped. ## The nightly-spike safeguard Low average with a violent peak is common in databases: quiet all day, then an ETL job that saturates the tier at 3 a.m. Downsizing that database trades money for timeouts. When the trusted peak of the full series reaches 80%, the recommendation is suppressed regardless of the average. The headroom is real, just rarely used. A CPU series, when present, is attached as corroborating evidence. ## One named step down, priced for real The recommendation always names its target: the next objective down the DTU ladder in the same tier: S3 to S2, P2 to P1. The dollar figure is the actual rate difference between those two objectives in your region. Three cases abstain by design: vCore-model databases (no DTU ladder to walk), bottom-rung objectives like S0, P1, and Basic (nowhere to go), and missing rate data (nothing honest to print). ## Read your own DTU curve ```bash az monitor metrics list \ --resource "/subscriptions//resourceGroups//providers/Microsoft.Sql/servers//databases/" \ --metric dtu_consumption_percent \ --interval PT1H --offset 30d --aggregation Average Maximum ``` ## Scaling down is an online operation A service-objective change on Azure SQL is a hot resize, with no stop, no data movement you manage, and a brief connection blip at cutover. Scale one step, hold for a billing cycle, and check Query Performance Insight for regressions before considering another. Elastic-pool databases have the analogous lever in eDTU reduction on the pool. ## Rule inputs and access Reader, Monitoring Reader, and Cost Management Reader reproduce everything the rule sees. High severity reflects how often DTU databases are set-and-forgotten several sizes too large.