Your datastore is billed per provisioned throughput unit rather than per request — what are you charged for during an idle hour?

## Two ways to meter the same work The same capability is often sold under two different meters, and the difference is not a discount — it is which side carries the risk of the level being wrong. - **Consumption-metered (pay per request).** The meter counts work done. Zero traffic costs zero. The unit price is higher, because the provider is absorbing the peak on your behalf and you have committed to nothing. - **Provisioned.** You declare a throughput or capacity level. The meter runs on `level x time held`. Zero traffic costs the full level. The unit price is lower, because the provider knows what to reserve. It is worth being precise about the risk, because this is easy to state backwards. Provisioned pricing is cheaper per unit of work **when you use it**; you took on the risk of holding a level you may not need. That is a different bargain from a term commitment, where you promise future spend in return for a rate, and a different one again from reclaimable capacity, where the provider keeps the right to take the resource back. All three are cheaper than the plain metered rate, and they fail in different directions. ## What provisioned actually buys | Property | Provisioned level | Consumption-metered | |---|---|---| | Charge at zero traffic | Full level, unchanged | Zero | | Price per unit of work | Lower | Higher | | Behaviour above the level | Refused or throttled until raised | Served, and billed | | Who absorbs a spike | You, by holding headroom | The provider | | Number to watch | Utilisation of the held level | Request volume and its growth | | Reaction time | Level changes are an action you take | None needed | The second row and the third row are the whole trade. You pay less per unit and in return you own two operational obligations: keep the level high enough that real traffic is not throttled, and keep it low enough that you are not paying for air. Those pull in opposite directions, which is why utilisation becomes the metric that matters. A level running at a low fraction of its capacity is money spent on nothing; a level running near the ceiling is an incident waiting for the next traffic step. ## The utilisation crossover The choice has an arithmetic answer once you know your duty cycle. Take an illustrative pair of rates in arbitrary cost units: one provisioned unit costs **1 cost unit per hour** and covers up to **3,600 requests** in that hour; per-request pricing charges **0.0005 cost units per request**. - At 3,600 requests in the hour, per-request costs `3600 x 0.0005 = 1.8`, against 1.0 provisioned. Provisioned wins. - The two are equal at `1.0 / 0.0005 = 2,000 requests` in the hour — about **56% utilisation** of the level. - Below 2,000 requests an hour, per-request is cheaper; above it, provisioned is. Those numbers are invented, but the shape is the point: **the crossover is a utilisation percentage, not a traffic volume**. If your measured average utilisation sits comfortably above the crossover for most hours, hold the level. If your traffic is a daytime peak and an overnight trough, the average is what you pay for and the trough is what destroys the case. ## When provisioned is still right despite poor utilisation There are two honest reasons to hold a level you do not fully use. The first is **predictability**: a fixed level produces a bill you can forecast, and some organisations value that over a lower expected cost. The second is **latency and admission control**: a declared level is reserved, so behaviour at the peak is known, and the throttle is a deliberate ceiling rather than an unbounded bill. A per-request meter has no ceiling of its own, which means a runaway client or a retry storm converts directly into spend rather than into refusals. ## What goes wrong The common failure is a level set once during launch, sized for a peak that was guessed, and never revisited. Traffic patterns move, the team adds caching, the level stays. The bill is unchanged by any of it, because the meter never looked at traffic. The second failure is the mirror image: a level trimmed to the average, which throttles every afternoon, and an incident review that blames the datastore rather than the capacity decision. Both are found the same way — plot utilisation of the held level over a representative period and compare it with the crossover, rather than reading the bill total. Providers differ in how elastic this is. On some platforms the declared level can be adjusted continuously or scaled automatically between bounds, which blurs the distinction; on others a change is a deliberate operation with its own cadence. The mechanism to reason about is the same: you are paying for a level and a duration.