Right-size over-provisioned Azure SQL Database compute

Unlike most posture work, right-sizing SQL compute reduces the Azure bill directly, and it reduces it from the next billing hour. Azure SQL compute is charged per tier per hour, so dropping a database from eight vCores to four, or from an S6 to an S3, roughly halves its compute line item immediately and recurs every month after. There is no migration project and no new service to buy: the saving is the difference between the old tier and the new one, banked the same day the scale operation completes.

Frame each over-provisioned database as a recurring line you are paying that the workload does not justify. A database peaking at fifteen per cent utilisation on a tier sized for a hundred is carrying three or four levels of headroom you are renting and never use. The finance job is to total that wasted compute across the estate, the single databases, the elastic pools and the Managed Instances, and to separate the risk-free drops (large headroom, stable workload) from the few that need a short observation window before committing.

The arithmetic is the opposite of insurance: this is a saving with a near-zero cost to capture. The effort is the engineering time to read the utilisation, confirm the headroom and run one scale command per database. The only ongoing decision is where reserved capacity, which Microsoft documents at up to roughly thirty per cent off pay-as-you-go for a one or three year commit, and serverless auto-pause for intermittent databases, can compound the saving once the tier itself is right.

Priya is the finance partner running the Azure cost review. The SQL line is the largest single item on the bill and it has crept up for two years with no obvious cause. The instinct is not to challenge the engineering team on whether they need databases at all; it is to ask how much of the current spend is compute headroom that the workloads never touch. Because Azure SQL bills per tier per hour, every level of unused headroom is a recurring charge that drops off the bill the hour after the database is scaled down, with no migration and nothing new to buy.

Priya asks the team to map each database to its average and peak utilisation over the last month. Three large single databases sit flat below twenty per cent and drop two tiers each with room to spare. An elastic pool was sized for a peak that a retired tenant used to drive and now runs at a quarter of its eDTU. Two Managed Instance databases are genuinely busy and stay as they are. The list reframes as a savings plan: 'Four right-sizes bank a recurring monthly saving from the next billing hour at zero capture cost; once the tiers are correct, a reserved-capacity commit on the steady baseline takes roughly another third off the floor, and the two busy instances are left exactly as they are.' Right-sizing is not a cut to capability; it is the difference between paying for the workload and paying for headroom nobody uses.

The cost model here is unusually clean: the saving is immediate, recurring and quantifiable before you act. Azure SQL compute is charged per tier per hour, so the saving from a scale-down is exactly the price difference between the old tier and the new one, and it lands from the next billing hour with no migration and no capture cost. You can read the utilisation, price both tiers, and know the monthly saving before a single command runs.

Leaving it costs nothing dramatic in any single month, which is precisely the trap: a flat over-charge attracts no attention. The finance role is to total the wasted compute across every database, pool and instance, order the right-sizes by the size of the saving and the safety of the headroom, and then sequence reserved capacity after, not before, the tiers are correct, so the long-term commit discounts the real baseline rather than the inflated one. Serverless with auto-pause, which Microsoft now allows down to a fifteen-minute idle delay, takes intermittent dev and test databases further still by charging only for storage while they sit idle.

Databases are usually the most expensive line in an Azure subscription, and the most over-provisioned. A database provisioned large for a workload that never arrived, or that shrank years ago, keeps charging the full tier every hour regardless. Across an estate this compounds into a material, recurring spend that buys no performance, because the headroom is never touched.

The leadership question is not 'are our databases fast enough?' It is 'are we paying for capacity our workloads have never used?' The defensible end state is that every database, pool and instance is sized to its real utilisation with sensible headroom, that the savings from the over-provisioned ones have been banked, and that reserved capacity covers the steady baseline so the floor itself is discounted.

This is the rare cost lever that is also low risk. Scaling Azure SQL down is an online operation, the saving is immediate and recurring, and the only databases that need care are the few with spiky or seasonal peaks. For everything sitting flat at low utilisation, the only thing standing between the estate and a lower bill is someone reading the metric and running the command.

After a cost review flagged that database spend had outgrown revenue growth two years running, the CFO asked the obvious question at the next review: are we paying for database capacity we actually use? The honest answer at the time was that nobody knew, because tiers were set during migrations and one-off loads and never revisited, and the team measured success by 'the databases are fast' rather than by whether the size matched the workload.

The team's response was to stop treating tier size as a set-and-forget decision and start treating it as something measured against utilisation. They read the CPU and DTU consumption for every database, pool and instance, scaled down the ones sitting flat below their headroom, left the genuinely busy ones alone, and then put a reserved-capacity commit over the steady baseline that remained. The next time the CFO asked, the answer had changed from 'we think the sizes are fine' to 'every database is sized to its measured utilisation with sensible headroom, the over-provisioned ones have been banked, and the steady floor is on a reserved-capacity discount.' That shift, from sizing by the highest peak anyone could remember to sizing by what the workload actually uses, is the recurring saving this capability delivers, and the performance never changed because the headroom was never being used.

Database compute is usually the largest controllable line in a cloud bill and the one most likely to be carrying years of accumulated over-provisioning. Right-sizing it is the capability that converts that flat, unexamined charge into a recurring saving, and because the scale operation is online and reversible, it carries far less risk than most cost cuts of comparable size.

The cost of getting this wrong is paying, every month and indefinitely, for capacity no workload uses, and then potentially locking that waste into a multi-year reserved commit. The cost of fixing it is engineering time to read a metric and run a command. This is the rare class of decision where the saving is immediate and the risk is low, which is exactly the trade leadership should be quickest to approve, provided the order is right: right-size first, reserve second.