NoSQL database cost compared: DynamoDB vs Firestore vs Cosmos DB
DynamoDB, Firestore, and Cosmos DB price NoSQL differently, DynamoDB per capacity or request, Firestore per operation, Cosmos per request unit or serverless. The cheapest depends on read/write mix and traffic shape. This compares the models.
Quick answer
The three managed NoSQL databases meter differently: DynamoDB bills read and write capacity units (provisioned or on-demand) plus storage, Firestore bills per document read, write, and delete plus storage, and Cosmos DB bills request units (provisioned, autoscale, or serverless) plus storage. The cheapest depends on your read/write mix and whether traffic is steady or spiky, all three reward efficient access patterns.
DynamoDB, Firestore, and Cosmos DB are the managed NoSQL offerings of the three major clouds, and they meter cost on different but analogous axes. All charge for throughput (however measured) and storage, and all reward the same thing: efficient data models and access patterns. The cheapest for a given workload depends on its shape, not the brand.
Three throughput models
| Database | Throughput billing | Modes |
|---|---|---|
| DynamoDB | Read/write capacity units | Provisioned or on-demand |
| Firestore | Per document read/write/delete | Pay-per-operation |
| Cosmos DB | Request units (RUs) | Provisioned, autoscale, or serverless |
DynamoDB bills capacity units, provisioned (reserve capacity, cheaper for steady load) or on-demand (per request, scales to zero), as in DynamoDB on-demand versus provisioned. Firestore bills per document operation, as in Firestore cost. Cosmos DB bills request units, with provisioned, autoscale, and serverless modes, as in Cosmos serverless.
Steady vs spiky, reads vs writes
Two workload properties decide cost across all three. Traffic shape: steady, predictable load favors provisioned/reserved capacity, while spiky or intermittent load favors on-demand or serverless that scales to zero. Read/write mix: writes cost more than reads on all three (and Firestore's per-write rate is notably higher than reads), so a write-heavy workload is priced differently from a read-heavy one. Map your workload to the right mode on any of them.
The shared optimization: efficient access
Every one rewards efficient data modeling and access: point reads over scans, indexes that match queries, avoiding over-reads, and caching hot data to deflect operations. A poorly-modeled workload is expensive on all three; a well-modeled one is cheap. So the optimization transfers across platforms.
Choosing on cost
The cheapest is usually the NoSQL database on the cloud where your application runs (avoiding cross-cloud latency and egress), run in the mode that matches your traffic shape, with an efficient data model. The per-unit rates are close enough that workload shape and access efficiency matter more than the platform, so choose by ecosystem and optimize the access pattern.
FAQ
Is DynamoDB, Firestore, or Cosmos DB cheapest?
It depends on your read/write mix and traffic shape, not the platform. All three charge for throughput and storage and reward efficient access patterns. The cheapest is usually the NoSQL database on the cloud where your app runs, in the mode (provisioned or on-demand/serverless) that matches your traffic, with an efficient data model.
How do NoSQL database pricing models differ?
DynamoDB bills read and write capacity units (provisioned or on-demand), Firestore bills per document read, write, and delete, and Cosmos DB bills request units (provisioned, autoscale, or serverless). The axes differ, but all charge for throughput plus storage and offer a steady-load and a scale-to-zero mode.
Do writes cost more than reads in NoSQL databases?
Yes, on all three. Writes are more expensive than reads (Firestore's per-write rate is notably higher than reads, and DynamoDB write capacity units cost more than read units), so a write-heavy workload is priced differently from a read-heavy one. Consider your read/write mix when comparing.
Should I choose provisioned or serverless NoSQL?
Steady, predictable load favors provisioned or reserved capacity (DynamoDB provisioned, Cosmos provisioned/autoscale), which is cheaper per operation. Spiky, intermittent, or unpredictable load favors on-demand or serverless (DynamoDB on-demand, Cosmos serverless, Firestore's pay-per-operation) that scales to zero. Match the mode to traffic shape.
What is the shared NoSQL cost optimization?
Efficient data modeling and access: point reads over scans, indexes that match queries, avoiding over-reads, and caching hot data to deflect operations. A poorly-modeled workload is expensive on DynamoDB, Firestore, and Cosmos alike; a well-modeled one is cheap. The optimization transfers across all three platforms.
Does C3X estimate NoSQL database cost?
C3X prices provisioned NoSQL resources (DynamoDB capacity, Cosmos throughput) from your Terraform. On-demand, serverless, and per-operation cost depends on read/write volume and access patterns, which you model as usage assumptions to compare across DynamoDB, Firestore, and Cosmos.
What to do next
Compare NoSQL options for your workload. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.
Pricing references
Related posts
- Azure Cosmos DB autoscale cost: when the 50% premium pays off
Cosmos DB autoscale raises the per-RU/s rate by 50 percent but scales throughput automatically between 10 percent and 100 percent of a maximum. For variable traffic it can be cheaper than standard provisioned; for flat traffic it is a needless premium. Here is the math.
- DynamoDB backup and restore cost: on-demand, PITR, and exports compared
DynamoDB offers on-demand backups, point-in-time recovery, and S3 exports, each priced differently. Here is what each costs per GB, when continuous backup is worth double the on-demand rate, and how restores and exports are billed.
- Azure Cosmos DB serverless cost: pay per request unit consumed
Cosmos DB serverless bills per request unit (RU) consumed plus storage, with no provisioned throughput to pay for when idle. It suits spiky or low-traffic workloads; steady high traffic is cheaper on provisioned throughput. Here is how to choose.
- Azure Cosmos DB RU cost optimization: stop over-provisioning throughput
Cosmos DB bills by provisioned RU/s (~$0.008 per 100 RU/s-hour) times region count. Over-provisioned throughput and needless multi-region writes are the big overspends. Here's how to right-size and which throughput model to pick.
Share this post
Try C3X on your own Terraform
Free and open source. No API key required. One command to install, one command to estimate.