Key-value and document stores trade the flexibility of SQL for one promise: if you can name the key, they'll find the data in a few milliseconds at any size. Every major cloud sells one, and they look alike on a slide. They differ underneath in ways that decide your design: how a key maps to a partition, how much one partition can take, what "consistent" means, and what you're billed for.
This page assumes the ideas in Partitioning by hash, Leaderless replication and the DynamoDB lesson. The Cassandra lesson covers the self-hosted wide-column side.
Side by side
| AWS | Google Cloud | Azure | Self-hosted | |
|---|---|---|---|---|
| Service | DynamoDB | Bigtable (wide-column) and Firestore (documents) | Cosmos DB | Cassandra, ScyllaDB |
| Data model | Items under a partition key, sorted by an optional sort key | Bigtable: rows sorted by row key, the only indexed value. Firestore: documents in collections, indexed fields | Items in containers, grouped into logical partitions by partition key | Wide rows by partition key, clustering columns |
| The limit that bites | One partition: 3,000 read units and 1,000 write units a second; item max 400 KB | Bigtable: hot row-key ranges. Firestore: new collections should ramp up from 500 operations a second | One logical partition: 20 GB and 10,000 RU/s | Hot partitions, large partitions, compaction |
| Consistency | Eventually consistent reads by default, strongly consistent on request | Bigtable: strong in one cluster, eventual by default across clusters | Five levels, from strong to eventual | Tunable per query (quorum sizes) |
| You pay for | Read and write request units (on-demand) or provisioned capacity, plus storage | Bigtable: nodes and storage. Firestore: document reads, writes and deletes | Request units (provisioned, autoscale or serverless) and storage | Machines, disks, people |