NoSQL pricing: DynamoDB vs Cosmos DB vs Firestore

By Rohit Athaide · Published 4 Nov 2026

Short answer: managed NoSQL databases bill by the work they do, not by a server size. That makes them cheap to start and hard to predict until you know your access pattern. Count reads, writes, item size and stored data, then price them in the mode that fits your traffic.

Key points

• Billing is per read and write, with item size and consistency affecting the count.
• Two modes: on-demand per operation, and provisioned capacity per hour.
• Storage includes indexes.
• Replication to other regions multiplies write cost.
• A relational database may be easier to predict if your data fits.

Which services are equivalent?

They are equivalent as managed document or key-value databases. Query features differ, so check yours against each before comparing price.

What are you billed for?

1. Reads and writes. Counted in operations or in capacity units. Read size, consistency level and item size change how many units one call uses.
2. Throughput. In provisioned mode you reserve a rate and pay for it all hour. In on-demand mode you pay per operation.
3. Storage. Gigabytes held per month, including indexes.
4. Extras. Backups, replication to other regions, and data out.

What does a worked example look like?

Made-up round numbers to show the method, not real prices or real unit sizes. An app does 50 reads and 10 writes per second on average on items of 4 KB. One read unit covers a 4 KB read and one write unit covers a 1 KB write.

1. Writes per second in units: 10 writes x 4 KB / 1 KB = 40 write units per second.
2. Reads per second in units: 50 x 1 = 50 read units per second.
3. Per month (2,592,000 s): writes = 103,680,000 units, reads = 129,600,000 units.

Provisioned looks seven times cheaper, but only if traffic really is flat. Real traffic peaks, so you provision for the peak: at 4 times the average, provisioned is 94.92, still below on-demand. If the peak is 10 times the average, provisioned reaches 237.30 and on-demand wins. The break-even is set by how peaky your traffic is.

What makes the bill grow?

• Large items. A bigger item uses more units per read or write.
• Strong consistency, which can double the read cost on some services.
• Full scans. Reading everything to find a few items.
• Many secondary indexes. Each one is written to on every change.
• Replication to several regions, which multiplies write cost.

Which mistakes are common?

• Choosing provisioned capacity before knowing the traffic shape.
• Storing large blobs in the database instead of object storage.
• Using scans where a key lookup would do.
• Adding indexes “just in case”.

Decision checklist

• What are reads and writes per second at average and peak?
• How large is a typical item?
• Is traffic flat or spiky?
• Would a relational database fit?

Next steps

Count reads and writes per second at average and peak, item size and total stored data, then price each service from its vendor page. See serverless or servers for thinking about pay-per-use. If a relational database fits your data, compare with managed PostgreSQL and managed vs self-hosted.