DTU-model Azure SQL databases averaging under 10% DTU that can drop one service objective

A DTU service objective is billed for its full size

In the DTU purchasing model each single database runs at a fixed service objective, such as S3 or P2, that bundles compute, memory and I/O. The objective, not the workload, sets the bill. Moving up and down is supported online: the scaling guide says a scale operation has a switch-over period in which connectivity drops briefly, which retry logic absorbs.

Databases are often created at a comfortable size and never revisited. When a month of metrics shows a database using a tenth of its DTUs, one step down usually leaves plenty of room.

Pulling DTU history for a database

az sql db list --resource-group my-rg --server my-server \
  --query "[].{name:name, objective:currentServiceObjectiveName, status:status}" -o table

az monitor metrics list --resource <database-resource-id> \
  --metric dtu_consumption_percent cpu_percent \
  --aggregation Average Maximum --interval PT1H --offset 30d

Look at both columns. The average says whether the database is oversized; the maximum says whether a smaller objective would have been overrun.

Thresholds and the one-step ladder

1. The database is online and has a DTU percentage series.
2. The 30-day average is below 10%.
3. The peak over the window is below 80%. A database that has touched 80% is left alone, however quiet it is on average.
4. The current objective has a lower rung in the same tier. Standard steps through S0, S1, S2, S3, S4, S6, S7, S9 and S12; Premium through P1, P2, P4, P6, P11 and P15.
5. Hourly rates for both the current and the target objective are known in the region, and the target is cheaper.

CPU percentage is added to the recommendation as supporting evidence when it is available.

Databases that are not stepped down

vCore databases have no DTU ladder and are outside this rule. Databases already on the bottom rung of their tier (Basic, S0 or P1) have nowhere to go without changing tier, which is a different decision. Missing prices, a missing metric or a peak at or above 80% all mean no finding; ZopNight does not fall back to a flat percentage of the bill. Databases that are consistently quiet and could share capacity are better candidates for Azure SQL Multiple Small DBs Could Use Elastic Pool.

Rate difference between two service objectives

monthly saving = database monthly cost x (1 - target objective rate / current objective rate)

A single rung keeps the change conservative. If the database is still quiet after the move, the rule can evaluate it again on its new objective.

Scaling the database down one objective

1. Review DTU and CPU in Azure Monitor and check Query Performance Insight for heavy queries.
2. Change the objective: az sql db update --resource-group my-rg --server my-server --name my-db --service-objective S2.
3. Watch DTU percentage for a week. If it climbs above 80% regularly, go back up.