Why Does Azure Cosmos DB Cost $68K/Year for a 5TB Feature Store?

Last week an engineer sent me their Azure bill. Cosmos DB alone: ~$5,700/month. For a read-heavy feature store serving ML models.

For the same workload, a BoulderKV-style architecture (object storage + local cache) comes out to ~$2,500/month under reasonable assumptions.

“Is this normal?”

Yes, if you’re running Cosmos DB at scale with multi-region replication.

A Real Workload

Specs:

• 5TB of feature data (embeddings, signals, model inputs)
• 10K reads/sec (every inference hits the store)
• 100 writes/sec (feature updates)
• 3 regions (East US, North Europe, East Asia)
• 95% reads, 5% writes (classic pattern)

Nothing exotic. Standard production setup. Let’s see what it costs.

Azure Cosmos DB Costs

Assumptions (based on Microsoft docs for East US, North Europe, East Asia):

• 1 KB items and point reads
• 1 RU per 1 KB read and 5 RUs per 1 KB write
• $0.008 per 100 RU/s per hour (single-write provisioned throughput)
• $0.25/GB-month storage
• $0.05/GB data transfer out from North America/Europe to other regions
• Single-write region (East US), multi-region reads (costs billed per region)

That yields 10,500 RU/s total per region:

• Reads: 10,000 × 1 RU = 10,000 RU/s
• Writes: 100 × 5 RU = 500 RU/s

Here’s the cost breakdown:

Why so much? Cosmos DB bills provisioned throughput and storage in every region you replicate to, and cross-region data transfer is charged separately. For read-heavy workloads, RU/s is the dominant cost driver. These totals already include replication because we multiply RU and storage by the region count.

What’s Not Included

These costs can push your bill higher:

• Automatic indexing overhead (increases storage and RU usage)
• Availability Zones (RU/s multiplied by 1.25 per AZ)
• Multi-region writes (higher RU/s rate)
• Backups, analytical store, dedicated gateways

The Object Storage Alternative

If your workload is read-heavy and data changes infrequently, a different architecture often wins on cost:

1. Writes go to object storage (Blob/S3/R2)
2. Reads hit local cache first (memory or SSD)
3. Cache misses fall back to object storage (10–20ms)
4. Async replication across regions (eventually consistent)

The key difference: you stop paying for every read. With high cache hit rates, most reads never touch object storage and incur no per-request compute cost.

That’s exactly what BoulderKV is built for: read-heavy workloads where the data already lives in object storage.

Cosmos DB vs BoulderKV

Here’s the same workload with BoulderKV (Blob + local disk cache):

BoulderKV assumptions: 5 TB stored in Azure Blob hot tier at $0.021/GB-month (Microsoft Learn sample price), 2 NVMe cache nodes per region at $0.50/hr each, and the same 1 KB write replication traffic (≈518 GB/month at $0.05/GB). This assumes LRS in each region (no GRS/RA-GRS). Adjust these to match your VM size, cache strategy, region pricing, and redundancy.

When Cosmos DB Is Actually the Right Choice

Cosmos DB is still a great fit when you need:

✓ Strict consistency and global distribution out of the box

✓ Write-heavy workloads with unpredictable traffic

✓ Fully managed operations (no cache layers, no tuning)

Conclusion

Cosmos DB is powerful, fast, and globally consistent. But for read-heavy feature stores, its RU-based pricing can still add up fast—especially when you replicate across regions. If you can tolerate eventual consistency and serve most reads from cache, an object-storage architecture can deliver similar latency at a fraction of the cost.

BoulderKV is a global, read-optimized key-value store built on object storage for ML feature stores, inference caches, and other read-heavy workloads. Building in public—join the early access program.

Join early access

Questions or feedback? Email hello@boulderkv.com