Choose Cosmos DB serverless for bursty low-traffic workloads

Provisioned Cosmos DB is a fixed monthly commitment dressed up as a per-second number. A container at the 400 RU/s manual minimum is billed for that floor every hour of the month regardless of how many requests it serves, so an account that is genuinely busy for an hour a day is paying for roughly twenty-three hours of idle reservation. Serverless deletes that floor: you pay per million RUs consumed plus storage, and an account that sits idle overnight contributes nothing for those hours. For the right workload the saving is not a trim, it is removing a standing charge you were paying to do nothing.

The saving is real but the cases are specific, so treat this as a targeted move rather than a blanket policy. The accounts worth converting are the bursty, low-traffic ones: dev and test databases, internal tools, low-volume back-office services, early-stage products with sparse traffic. A steady, high-throughput production workload is cheaper on provisioned, often cheaper still on autoscale or with reserved capacity, so serverless there would raise the bill. The finance job is to separate the genuinely intermittent accounts, where consumption billing pays back immediately, from the steady ones where it would not.

The arithmetic is favourable because the downside is bounded. The change costs engineering time to stand up a serverless account and migrate the data, and the recurring cost only ever falls for a workload that was paying for idle reservation. The one variable to watch is predictability: serverless trades a fixed monthly line for a usage-driven one, so the bill follows demand. For a low-traffic account that is exactly the point, and the absolute numbers are small enough that the variance is comfortable.

Priya is the finance partner reviewing a cloud bill where Cosmos DB shows up as a cluster of small, suspiciously steady charges. The instinct is not to ask the team to cut databases; it is to ask which of these charges are for throughput that is actually being used. Each provisioned account bills its reserved floor every hour, so a dev database that is touched a few times a week and an internal tool that is busy for an hour each morning both look like full-time costs on the bill even though their real usage is a rounding error.

Priya asks the team to line up the provisioned accounts against Advisor's idle and low-activity flags and sort them by how bursty they are. The dev and internal-tool accounts are bursty and low-traffic: clear serverless candidates where the saving is immediate because the idle hours stop costing anything. The steady production order store is deliberately left out, because at constant high throughput it is cheaper on provisioned and cheaper still with reserved capacity. The finance pack reads: 'Four low-traffic accounts move to serverless and stop paying for idle reservation; one production account stays provisioned on purpose; the only spend is a one-off migration, and the recurring cost falls from day one.'

The cost model here is unusually clean. For a genuinely bursty, low-traffic account, moving to serverless can only lower the recurring bill, because you stop paying the reserved floor during the idle hours that dominate the workload. There is no new standing charge introduced; the line simply shrinks to track real usage. That makes these accounts some of the easiest savings to approve on the whole estate, with a one-off migration as the only spend.

The discipline is in qualifying the candidates rather than in justifying the saving. Serverless wins on accounts with a low average-to-peak ratio and loses on steady, high-throughput ones, where provisioned, autoscale or reserved capacity is cheaper. So the finance role is to insist the team sort accounts by traffic shape before converting any, ring-fence the steady production workloads as deliberate exceptions, and report the saving as recurring spend removed from the idle accounts rather than as a headline percentage that would not survive contact with the steady ones.

Reserved database capacity is one of the quietest forms of waste in a cloud estate. A provisioned Cosmos DB account bills its floor every hour, so a database that is busy for an hour a day still costs a full day, every day, and nobody notices because each account is small. Across an estate of internal tools, dev databases and low-traffic services, those floors add up to a standing charge for capacity that is idle most of the time.

The leadership question is not 'is the database fast enough?' It is 'are we paying for throughput we reserve but rarely use?' For bursty, low-traffic workloads the answer is usually yes, and serverless is the lever that turns it off: pay for what is consumed, nothing for the idle hours. It is a near risk-free saving for the accounts it fits, because the workload behaviour is unchanged and only the billing model moves.

This is a cost decision, not a security one, and it has a clean shape. The win is concentrated in the intermittent, low-volume accounts; the steady production workloads are deliberately left on provisioned or reserved capacity where they are cheaper. The goal is not 'serverless everywhere'. It is 'the right billing model on each account, so we stop paying a fixed price for variable demand.'

After a cost review flagged that the database line on the cloud bill had crept up while the product was still pre-revenue, the CFO asked the obvious question: are we paying for capacity we are not using? The honest answer was that nobody had matched each database's billing model to how it was actually used; every new Cosmos DB account had been stood up as provisioned by default, floor and all, regardless of whether it ever saw sustained traffic.

The team's response was to stop defaulting to provisioned and start choosing per account. They listed every Cosmos DB account, separated the bursty, low-traffic ones from the steady production stores, moved the intermittent accounts onto serverless so the idle hours stopped costing anything, and left the steady workloads on provisioned where they are cheaper. The recurring database spend on the low-traffic estate dropped, and the next time the CFO asked, the answer had changed from 'we think the databases are fine' to 'each account is on the billing model that matches its traffic, so we no longer pay a fixed price for capacity we use in bursts.' That shift, from a habit of reserving everything to deliberately matching billing to demand, is the saving this capability delivers.

Nearly every cloud estate carries a long tail of small databases stood up as provisioned out of habit, each quietly billing a reserved floor it rarely uses. Individually none is worth a meeting; together they are a standing charge for idle capacity that scales with the number of accounts rather than with the work being done. Matching the billing model to the traffic shape is the lever that turns that tail off without changing how any of the databases behave.

The cost of getting this right is a one-off migration per account and the discipline to choose serverless deliberately for new low-traffic databases; the cost of leaving it is a recurring bill that grows with every new account. This is the rare class of saving where the workload is untouched, the risk is bounded to predictability on accounts that are low-volume anyway, and the recurring spend can only fall, which is exactly the kind of trade leadership should approve quickly.