Production vCore Azure SQL databases with steady CPU and no reserved capacity

What SQL reserved capacity discounts, and what it cannot

Azure SQL reserved capacity is a one- or three-year commitment to a number of vCores in a region, deployment type and performance tier. Matching databases pick it up automatically with no failover or downtime, and vCore size flexibility lets you scale within the tier without losing the benefit. It covers compute on primary and billable secondary replicas, but not storage, networking or software, and it does not renew itself.

Two limits shape this rule. Microsoft states you cannot reserve DTU-based (Basic, Standard or Premium) databases. And the discount is applied hour by hour to running databases, so a database that is not busy for most of the month gets less value from it.

Reading a server’s databases and their compute model

az sql db list --resource-group my-rg --server my-sqlserver \
  --query "[].{name:name, sku:currentServiceObjectiveName, tier:currentSku.tier, vcores:currentSku.capacity}" \
  -o table

For a vCore candidate, confirm the CPU level over the last 30 days:

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

vCore databases show tiers such as GeneralPurpose or BusinessCritical. Service objectives with _S_ in them, such as GP_S_Gen5_2, are serverless.

Five gates a database has to clear

1. A production signal: a name with prod, production, prd or live, or a production environment tag.
2. No reservation or savings plan already covers it, and no reserved=true tag.
3. It is not serverless and its tier is not Basic, Standard or Premium (DTU).
4. At least 60 days of history and at least 70% uptime.
5. The vCore CPU percent metric averages 30% or more. DTU percentage is not accepted as evidence, since a DTU database could not use the reservation anyway.

Databases ZopNight will not push into a commitment

Serverless and DTU databases are skipped outright. Any database with unknown uptime, short history or no vCore CPU data is skipped as well, because an unverified signal counts as a fail. If the break-even comparison shows the reservation costing at least as much as the database does now, ZopNight raises nothing.

Break-even on the hours the database actually runs

current month   = what the database is billed now, for the hours it actually ran
reserved month  = 1-year reserved hourly rate x 730
saving          = current month - reserved month

A database that runs part-time therefore does not get credited with a full-time discount. When the break-even comparison cannot be made, ZopNight falls back to a discount derived from the rate tiers, and raises nothing when those rates are missing or look unsound.

Purchasing SQL reserved capacity

1. Confirm the database will run in this tier and region for at least 12 months.
2. Add up vCores per region and tier across the databases and pools that should share it.
3. In the portal, open Reservations, select Add and SQL Database, pick vCore (plus a separate vCore ZR reservation if you also want to cover the zone-redundancy add-on on General Purpose databases), the scope, 1-year term and quantity.
4. Check the reservation’s utilization after a few days.