Cosmos DB: Cost Optimization Strategies

Azure Cosmos DB is powerful but can be expensive if misconfigured. The “Request Unit” (RU) model abstracts hardware, but understanding it is key to cost control. This guide covers partition key selection, indexing policies, and the new Autoscale throughput.

Understanding Request Units (RU)

1 RU = 1 Read of a 1KB document by ID. Queries are more expensive.

• Point Read (ID + Partition Key): ~1 RU.
• Query (SELECT * FROM c): 2.5 RU minimum.
• Cross-Partition Query: Expensive + High Latency.

The Partition Key is King

Your choice of partition key determines scalability and cost.

• Good Key: High cardinality (e.g., `UserId`, `DeviceId`). Distributes storage and requests evenly.
• Bad Key: `Date` (Hot partition for today), `Status` (Only a few values).

Indexing Policies

By default, Cosmos DB indexes *everything*. This doubles write costs. Exclude paths you don’t query.

{
  "indexingMode": "consistent",
  "includedPaths": [
    { "path": "/username/?" },
    { "path": "/email/?" }
  ],
  "excludedPaths": [
    { "path": "/*" }, // Optimization: Exclude everything else
    { "path": "/_etag/?" }
  ]
}

Autoscale Throughput

Introduced in Spring 2020, Autoscale allows you to set a max RU/s. Cosmos DB scales between 10% and 100% of that max based on load.

• Manual 1000 RU/s: Billed 1000 RU/s 24/7.
• Autoscale 1000 RU/s: Scales between 100 and 1000. Great for variable workloads.

Key Takeaways

• Always perform **Point Reads** when possible.
• Optimize **Indexing Policy** to reduce write costs.
• Use **Autoscale** for unpredictable workloads (dev/test/daytime apps).
• Use the local emulator for development to save 100% of costs.