# Azure SQL Reserved Capacity > Production vCore Azure SQL databases running pay-as-you-go are flagged by RC-231 once they prove 60+ days of history, at least 70% uptime, and measured SQLCpuPercent of 30% or more. Savings come from a break-even comparison at 730 hours/month, falling back to a conservative 20% fraction; DTU and serverless tiers are excluded. Source: https://zop.dev/integrations/azure/recommendations/azure-sql-reserved-capacity Updated: 2026-08-19 --- ## Reserved capacity is a vCore-only product Azure sells SQL Database reserved capacity only for the vCore purchasing model. A DTU-tier database (Basic, Standard, Premium) cannot buy a reservation at all, so recommending one would be un-purchasable advice. RC-231 reads the discoverer-stamped `sku_tier` and abstains on any known DTU tier; serverless databases (SKU containing `_S_`) are also skipped, since reserved capacity does not apply to them. Even the utilization evidence respects this split: only the vCore meter `SQLCpuPercent` counts, so a database showing only `DTUPercentage` fails the utilization axis on purpose. ## What a database must prove before a 12-month lock-in A reservation is irreversible spend, so the rule demands evidence on three axes, all fail-closed: at least 60 days of observed history, uptime of 70% or higher, and a measured `SQLCpuPercent` average of 30% or more over the 30-day metric window. Unknown history, unknown uptime, or an unmeasured CPU series each mean abstain. A present-but-empty metric series (a stopped or unmonitored database) is treated as unverified, never as a measured 0%. An underutilized database is told, implicitly, to rightsize first and commit smaller later. On top of that, the database must look like production: a prod name pattern (prod, production, prd, live) or an authoritative environment tag. ## The percentage is derived, not advertised When tier rates are available, the rule prices the reservation at 730 hours/month against on-demand billed on measured running hours. A part-time database therefore never draws the full 24/7 discount. Its saving is capped at the real break-even net, and if the reservation would cost more than current spend, the rule returns nothing. Only when break-even inputs are missing does it fall back to a fraction of monthly cost, using a deliberately conservative 20%, which sits inside Microsoft's published ~16–33% band for 1-year SQL reserved capacity. The headline percentage is always recomputed from the emitted dollar figure, so the two can never disagree. ## Databases already covered are skipped Existing Reservation or SavingsPlan coverage on the resource, or a `reserved=true` tag, suppresses the finding. Cost inputs come through ZopNight's pricing pipeline (**Cost Management Reader**); metrics come via **Monitoring Reader**. ## List candidate databases yourself ```bash az sql db list --resource-group --server \ --query "[].{name:name, tier:sku.tier, capacity:sku.capacity}" -o table ``` Databases showing `GeneralPurpose`, `BusinessCritical`, or `Hyperscale` are vCore and reservation-eligible; `Basic`/`Standard`/`Premium` rows are DTU and out of scope.