Is the '1 RU per KB read, 5 RU per KB write' figure exact for every Cosmos DB workload?

It's the documented baseline for a simple point read/point write against a single-partition-key document, real workloads doing cross-partition queries, complex WHERE clauses, stored procedures, or large batch operations consume meaningfully more RU per operation than this baseline. Use this calculator for a first-pass estimate on point-operation-dominated workloads, and validate against the actual RU charge reported by the SDK for anything doing more complex queries.

Does switching indexing policy to none actually break the ability to query the container at all?

Not entirely, a container with indexing policy none can still be queried by its id and partition key (a lookup path that doesn't require the index), but any query filtering, sorting, or aggregating on other fields requires the automatic indexing that none disables, this makes none appropriate only for containers that are genuinely accessed exclusively by ID, not a general-purpose 'lower my RU cost' switch.

What actually determines the serverless-versus-provisioned recommendation this tool gives?

The tool compares calculated total RU/s against a fixed threshold (recommending serverless below roughly 50 RU/s) and also compares the estimated monthly cost under each pricing model, recommending serverless if it comes out meaningfully cheaper (by more than a 20% margin) for the given workload profile. For a workload right at the boundary, it's worth checking both estimates directly rather than relying solely on the tool's binary recommendation.

Azure Cosmos DB Throughput Calculator

StorageAzure

Calculate Cosmos DB RU throughput requirements with per-container workload estimates, autoscale settings, and indexing policies.

Workload Parameters

Avg Document Size (KB)

Indexing Policy

Point Reads/Second

Point Writes/Second

Base cost: 1 RU per 1KB read, 5 RU per 1KB write. Larger documents scale linearly.

Raw Output

Output will appear here...

What This Tool Does

Estimates Cosmos DB RU/s needs from document size, point-read/write rates, and indexing policy, using the documented baseline that a 1KB point read costs roughly 1 RU while a 1KB point write costs roughly 5 RU, scaling roughly linearly with document size beyond that. The indexing policy choice materially changes write cost: switching from the default consistent indexing to none removes per-write indexing overhead entirely (at the cost of losing the ability to query on anything but ID), which is the single most impactful lever in this calculator for a write-heavy workload that only ever does point reads/writes and never queries by non-ID fields.

Technical Details

The calculator computes readRUPerOp as roughly 1 RU times the document size in KB (rounded up), and writeRUPerOp as roughly 5 RU times size times an indexing-policy-dependent multiplier (consistent indexing adds the most overhead, none adds none), multiplies each by the given ops/second, sums to a total RU/s, then computes both a provisioned cost (rounded up to the nearest 100 RU/s, billed monthly) and a serverless cost (billed per RU consumed) to recommend whichever pricing model comes out cheaper for the given workload profile, flagging when the result falls under the 400 RU/s provisioned minimum or over roughly 1M RU/s where partitioning strategy needs review.

Common Use Cases

1Comparing total RU/s under consistent versus none indexing policy for a workload doing only point reads/writes by ID, since removing indexing overhead can meaningfully reduce write RU cost for a workload that never actually needs to query by other fields.
2Using the tool's provisioned-versus-serverless cost comparison to decide capacity mode for a new container, since a low, spiky, or unpredictable RU/s requirement (as flagged when totalRUs is under 400, the provisioned minimum) often favors serverless pricing instead.
3Checking the warning that appears when calculated RU/s falls below 400, the documented minimum provisioned throughput per container, so a genuinely low-throughput workload isn't provisioned at a rate below what Cosmos DB actually requires as a floor.
4Modeling document size increases (say, from 2KB to 10KB average) against read/write RU cost before a schema change ships, since RU cost scales with document size and an unplanned schema bloat can meaningfully inflate provisioned throughput cost.

Common Questions

Is the '1 RU per KB read, 5 RU per KB write' figure exact for every Cosmos DB workload?: It's the documented baseline for a simple point read/point write against a single-partition-key document, real workloads doing cross-partition queries, complex WHERE clauses, stored procedures, or large batch operations consume meaningfully more RU per operation than this baseline. Use this calculator for a first-pass estimate on point-operation-dominated workloads, and validate against the actual RU charge reported by the SDK for anything doing more complex queries.
Does switching indexing policy to none actually break the ability to query the container at all?: Not entirely, a container with indexing policy none can still be queried by its id and partition key (a lookup path that doesn't require the index), but any query filtering, sorting, or aggregating on other fields requires the automatic indexing that none disables, this makes none appropriate only for containers that are genuinely accessed exclusively by ID, not a general-purpose 'lower my RU cost' switch.
What actually determines the serverless-versus-provisioned recommendation this tool gives?: The tool compares calculated total RU/s against a fixed threshold (recommending serverless below roughly 50 RU/s) and also compares the estimated monthly cost under each pricing model, recommending serverless if it comes out meaningfully cheaper (by more than a 20% margin) for the given workload profile. For a workload right at the boundary, it's worth checking both estimates directly rather than relying solely on the tool's binary recommendation.

Expert Tips

TIP

None indexing policy is a real cost lever but only safe for containers genuinely queried exclusively by ID, verify your actual query patterns before switching, a container that later needs to add even one filtered query breaks under none indexing.

TIP

The RU-per-KB baseline this calculator uses is for simple point operations, any workload doing cross-partition queries, joins, or stored procedures will see meaningfully higher real-world RU consumption than this estimate predicts, treat the output as a floor, not a ceiling.

TIP

The 400 RU/s provisioned minimum applies per container (or per database if using database-level shared throughput), a calculated estimate well under 400 RU/s is a strong signal to seriously evaluate serverless pricing instead of assuming the provisioned minimum is a rounding error.

Related Learning Guides

Storage Account Types22 min read
Cosmos DB Consistency Levels24 min read

Was this tool helpful?

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.