NoSQL database cost compared: DynamoDB vs Firestore vs Cosmos DB

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.