Request Units & Cost

Most engineers come from a relational world where database cost is a fuzzy “size of the box × storage volume”. Cosmos breaks that mental model. Every operation has a price tag in RUs, and your monthly bill is just the sum of those price tags. Once you internalize the math, your bill stops being mysterious.

This lesson is the math.

What a Request Unit actually is

An RU is a normalized blend of CPU + memory + IOPS for one operation. Microsoft calibrated the unit so that reading a single 1 KB document by id + partitionKey costs exactly 1 RU. Everything else is scaled relative to that anchor.

Why a blend? Because a database operation isn’t just disk I/O. A query parses, plans, scans, deserializes, applies filters, projects fields — each of those touches CPU and memory. If Cosmos charged you in raw IOPS, write-heavy workloads would underpay (most of their cost is index updates, not disk seeks); query-heavy workloads would overpay. The RU normalizes all of it into one number.

The price tag for every operation

Here’s the cheat sheet most engineers eventually memorize:

A few patterns worth internalizing:

• Reads are cheap, writes are 5–7×. If your app is 10:1 read-to-write, your cost is dominated by reads. If 1:1, writes dominate.
• Doc size scales the cost roughly linearly above 1 KB, more aggressively for very large docs.
• Query cost is about scan, not result size. If your filter eliminates 90 % of docs at the index, the query is cheap. If it filters in code after scan, you pay for everything you scanned.

The three pricing modes

Cosmos sells RUs three ways. The right one depends on your workload’s shape.

Provisioned throughput

You set a fixed RU/s. Cosmos guarantees that capacity 24/7. Cheapest at steady utilization (60 %+).

1,000 RU/s × $0.008/hour × 730 hours = $58/month

Use for production workloads with predictable traffic.

Autoscale

You set a max; Cosmos scales between max/10 and max based on actual traffic. Costs 1.5× provisioned per RU consumed, but you stop overprovisioning for the peak.

10,000 RU/s autoscale max → fluctuates 1,000–10,000
You're billed at max / 10 per hour as a floor + actual usage

The math — autoscale wins when peak/average > 1.5×. For business-hours traffic, end-of-month cron jobs, or any workload with a 5–10× spike pattern, it’s a clear win.

Serverless

No provisioning at all. Pay $0.25 per million RUs consumed. Hard cap of 5,000 RU/s per container.

Use for:

• Dev/test environments
• Prototypes and side projects
• Apps with low traffic that spikes occasionally
• Workloads under ~1M RUs/month (often free under Azure free tier)

Modeling your bill before you ship

You can predict your monthly RU cost from a napkin:

RUs/month = (reads × 1) + (writes × 6) + (queries × 8) + (cross-partition × 30)

For a SaaS app with:

• 10M reads/day → 300M reads/month × 1 RU = 300M RUs
• 1M writes/day → 30M writes/month × 6 RU = 180M RUs
• 100K queries/day → 3M queries/month × 8 RU = 24M RUs

That’s ~504M RUs/month, peaking at maybe 10× the average per second. So 50,000 peak RU/s. On autoscale max 50,000 (floor 5,000), the bill lands around $2,200/month.

Now do the same exercise for one bad cross-partition query running 100 times/day at 30 RUs each — that’s 90,000 RUs/month. Trivial. Now make it 100,000 times/day — that’s 90M RUs/month, bigger than your write traffic. This is how a cost regression sneaks in.

The five biggest cost levers

In rough order of impact:

1. Right-size indexing. Default policy indexes everything. If you only query 5 paths but write 50, you’re paying 10× too much per write. Lesson V07 has the playbook.
2. Pin queries to a single partition. A WHERE partitionKey = '...' AND ... query is 10–30× cheaper than the same query without the key.
3. Don’t hydrate full docs when you only need a few fields. A query with SELECT c.id, c.name scans the same as SELECT * but is cheaper to deserialize.
4. Batch reads when you can. A single point-read of one doc is 1 RU. A batch operation reading 10 docs is also ~10 RUs but one network round-trip — the savings is in latency, not RUs, but it matters.
5. Use the right pricing mode. Switching from provisioned to autoscale saves 30 %+ on workloads with peak/avg > 1.5.

Where this lesson connects

• V02 Partitioning — partition design is RU design. Hot partitions throttle even when the container as a whole is under-provisioned.
• V06 Querying — write queries that index-scan instead of doc-scan.
• V07 Indexing — the single biggest write-cost lever.
• V10 Monitoring — read the x-ms-request-charge header religiously; alert on RU consumption percentile by operation type.

If you remember three things from this lesson —

1. Read the request-charge header during development. Every PR should know what the RUs are.
2. Index only what you query.
3. The partition key is also a cost decision, not just a data-modeling one.

— you’ll spend a fraction of what most teams do.