The pricing page finally shows a number: $0.000147 per request unit (RU). At first glance, that looks like it's in the same ballpark as DynamoDB on-demand ($0.000147 per WCU, $0.00029 per RCU). But we all know the devil is in the details, and with Cosmos DB, it always is.
Has anyone run a real, reproducible workload on the new serverless tier yet? I'm talking about:
* Sustained throughput patterns vs. bursty spikes.
* The actual cost impact of storage (still separate and not cheap).
* How the "request unit" calculation compares for identical operations in DynamoDB vs. Cosmos DB. Their RU calculators have been historically optimistic.
My initial suspicion is that for true, variable, low-volume workloads, it might finally be viable. But for anything with steady-state traffic, the provisioned throughput model will still be cheaper, and the complex tiering makes forecasting a nightmare.
I need to see benchmarks that aren't from a Microsoft case study. If you've migrated a test table from DynamoDB or Firestore, post your numbers. Specifically:
* Workload profile (read/write ratio, item size).
* Observed RU consumption for standard operations.
* The final line item for compute + storage.
Until then, "competitive" is just a marketing term.
Show me the query.
Totally agree about needing real numbers. I just finished a quick-and-dirty migration test on a side project's activity log, moving it from DynamoDB on-demand.
The workload's pretty bursty, maybe 50 reads for every write, small items (around 2KB). For a simple `get_item` by partition key, DynamoDB used 0.5 RCU, while the same op in Cosmos DB consumed about 3 RUs. That's the multiplier you have to watch for.
My napkin math for last month's pattern shows Cosmos DB would've been about 40% more expensive, even with the similar looking per-unit cost, purely because of that RU inflation. The storage line item was a nasty surprise, too. It feels viable only if your ops are *super* light and infrequent, or you're already deep in the Azure ecosystem. I'd still love to see someone else's comparison with larger items or more complex queries.
Great point about the RU calculators being optimistic, I've seen that firsthand. In my tests with a small e-commerce dataset, a basic query that DynamoDB handled with 1 RCU consistently took 5 RUs in Cosmos DB serverless. That multiplier changes everything.
You're right to focus on storage costs, they're the silent budget killer. It's priced per GB-month, not per operation, so infrequent workloads still carry that base fee. Makes it tricky for truly spiky use cases.
If your pattern is predictable even 80% of the time, you're probably better off with a small provisioned throughput floor and autoscale on top. But I'd still like to see more benchmarks from real migrations, especially with mixed read/write patterns.
Always A/B test.