The Ultimate Key-Value Store Comparison
1. Redis
The “Swiss Army Knife” of Key-Value Stores
If you don’t know what to pick, you usually pick Redis. But be careful. Interviewers love to ask why you picked it over Memcached. Redis is an in-memory data structure store, meaning it doesn’t just store strings but also it understands lists, sets, and hashes.
What is it? In-memory, single-threaded (mostly), sub-millisecond latency store.
Key Features: Persistence (RDB/AOF), Pub/Sub, Lua scripting, Geospatial support.
Use this when:
You need complex data structures (Leaderboards with Sorted Sets).
You need persistence (you don’t want to lose the cache on restart).
You are building a rate limiter or a job queue.
Don’t use this when:
You need multi-threaded performance (see Memcached).
Your dataset is larger than RAM (though Redis on Flash exists, it’s not the default).
2. DynamoDB
The “I Don’t Want to Manage Servers” One
Amazon’s answer to “How do we make sure this never goes down?”. It’s a fully managed, serverless key-value and document database that delivers single-digit millisecond performance at any scale.
What is it? A managed, serverless, distributed NoSQL database. Uses a B-tree under the hood (mostly).
Key Features: Infinite scaling (literally), integrated with AWS IAM, Streams for event-driven architecture.
Use this when:
You are in an AWS ecosystem (obviously).
You need predictable performance regardless of scale (1GB or 1PB, it behaves the same).
You need a “Shopping Cart” or “User Profile” store that handles millions of TPS.
Don’t use this when:
You need complex joins or aggregations.
You are on a tight budget (provisioned throughput can get pricey if you miscalculate).
3. FoundationDB
The “ACID Compliant” Distributed Beast
Apple bought this company for a reason. FoundationDB is unique because it provides ACID transactions across a distributed cluster. Most NoSQL DBs give up consistency for availability (AP in CAP theorem), but FoundationDB fights for Consistency.
What is it? A distributed, ordered key-value store with strong ACID guarantees.
Key Features: The “Onion” architecture. The core is a KV store, and you build “Layers” (like SQL or Graph) on top of it.
Use this when:
You need strict correctness (financial transactions) but on a distributed scale.
You want to build your own database on top of a reliable engine.
Don’t use this when:
You need a simple cache.
You want a “batteries included” database with a query language like SQL out of the box (unless you use a Layer).
4. Cassandra
The “Write Heavy” Heavyweight
Okay, technically this is a “Wide-Column Store,” but in system design, we often treat it as a KV store where the value is a map of columns. It’s famous for being used by Facebook and Instagram.
What is it? A masterless, distributed database optimized for heavy writes.
Key Features: Tunable Consistency (you can trade accuracy for speed), Peer-to-Peer architecture (no single point of failure), LSM Trees for fast writes.
Use this when:
You have a write-heavy workload (e.g., storing Discord chat logs or IoT sensor data).
You need high availability (AP) and can tolerate “Eventual Consistency.”
Don’t use this when:
You need ACID transactions.
You need frequent updates/deletes (Cassandra hates tombstones).
5. Riak DB
The “Amazon Dynamo” Sibling
Riak is an implementation of the famous Amazon Dynamo paper. It focuses purely on availability. If a node goes down, Riak doesn’t care. It just lets a neighbor handle the write.
What is it? A distributed, decentralized key-value store.
Key Features: CRDTs (Conflict-free Replicated Data Types) to handle merge conflicts automatically.
Use this when:
Your system MUST remain available even if half the data center burns down (e.g., Shopping Carts).
You are dealing with network partitions often.
Don’t use this when:
You need strong consistency.
6. Etcd
The “Brain” of the Cluster
If you’ve used Kubernetes, you’ve used Etcd. It’s not for storing user data; it’s for storing the state of your system.
What is it? A strongly consistent, distributed key-value store. Uses the Raft consensus algorithm.
Key Features: Watch API (clients get notified when keys change), Lease primitives.
Use this when:
Service Discovery (who is the leader?).
Storing configuration data for a distributed system.
Distributed locking.
Don’t use this when:
You want to store large amounts of data. It has a tiny storage limit (usually a few GBs).
7. RocksDB
The “Embedded” Speedster
This is not a database server you connect to. It’s a C++ library you embed in your application. It was built by Facebook (forked from Google’s LevelDB) to exploit the full potential of fast storage like SSDs.
What is it? An embeddable persistent key-value store based on Log-Structured Merge (LSM) trees.
Key Features: Insane write throughput, tunable trade-offs (Space vs. Read vs. Write amplification).
Use this when:
You are building a database engine (CockroachDB and MySQL MyRocks use RocksDB under the hood!).
You need local, persistent, fast storage on a single node.
Don’t use this when:
You need a networked database server.
You need multi-machine replication out of the box.
8. LevelDB
The “OG” Embedded Store
Created by Jeff Dean and Sanjay Ghemawat at Google. It’s the predecessor to RocksDB. It’s simpler but single-threaded in some critical areas.
What is it? A fast key-value storage library providing an ordered mapping from string keys to string values.
Key Features: Snappy compression, simple architecture.
Use this when:
You need a lightweight embedded store for a browser (Chrome uses it for IndexedDB) or mobile app.
Don’t use this when:
You have high-concurrency server workloads (use RocksDB instead).
9. Memcached
The “Old School” Cache
Before Redis took over the world, Memcached was King. It is still widely used by giants like Meta because of its simplicity and multithreaded architecture.
What is it? A high-performance, distributed memory object caching system.
Key Features: Multithreaded architecture (scales well on big CPUs), extremely simple Key-Value model.
Use this when:
You need raw, simple caching power and have vertical scaling needs (multithreading).
You cache small, static objects (HTML fragments, session data).
Don’t use this when:
You need persistence (if you restart, data is gone).
You need advanced data types (Lists, Sets).
Till next time, happy learning!