Redis is the default for almost every cache workload now: it has data structures, persistence, pub-sub, and clustering in the box. Memcached is the right answer when the workload is a flat key-value cache and the team values the simplest possible operational story.
These tools live in different categories now. Redis is a wide platform that also caches well. Memcached is a single-purpose cache that does only one thing. Most teams pick Redis for the optionality. The teams who pick Memcached do so because that optionality is, for them, a cost.
Strings, lists, hashes, sets, sorted sets, bitmaps, HyperLogLogs, geospatial entries, streams. Each has dedicated commands (LPUSH, ZADD, HSET, GEOADD, XADD). The data-structure surface is the reason most teams choose Redis.
Byte blob. Clients can JSON-encode whatever they want, but atomic operations on individual fields are not available. INCR exists. That is the extent of structure.
RDB snapshots for point-in-time backups and AOF for an append-only log of every command, with tunable fsync. Configurable for "never lose more than 1s of writes." Persistence is optional; pure-cache mode is supported.
None. Restarts lose everything. This is intentional. It keeps the design simple and avoids the corruption-recovery story.
Single-threaded event loop for command execution. Redis 6+ added multi-threaded I/O but command dispatch is still serial. Predictable, no locking, but per-instance throughput is bounded by one core.
Multi-threaded. Scales close to linearly across cores up to about 16 threads. On a 32-core machine, Memcached out-throughputs a single Redis instance on simple GET/SET by 2-3x.
Redis Cluster is built in. Hash-slot sharding (16384 slots), automatic failover via Sentinel or Cluster mode, automatic resharding. Client libraries handle MOVED redirects.
No native clustering. Sharding is client-side, usually consistent hashing in the client library (ketama). Simple, but rebalancing is the operator’s problem.
Native Pub/Sub and Redis Streams, the latter with consumer groups, persistence, and message acks. Streams covers many event-driven needs without reaching for a full broker.
None.
Variable overhead per key, roughly 50-100 bytes for short keys. Multiple encoding schemes (ziplist, intset, listpack) compact small structures. MEMORY DOCTOR helps debug overhead.
Slab allocator with fixed page sizes. Lower per-key overhead, but memory can be wasted if value sizes do not fit slab boundaries. Tunable via -f and -n flags.
Redis Ltd. moved Redis to RSALv2 and SSPLv1 in 2024. Cloud vendors can no longer offer it as a service without a commercial agreement. AWS, GCP, and Oracle forked the BSD-era code to create Valkey, now under the Linux Foundation.
BSD 3-clause. Stable for two decades. No license-change events to worry about.
AWS ElastiCache (Redis and Valkey), GCP Memorystore, Azure Cache, Upstash, Redis Cloud, Aiven. Since the 2024 license change, most clouds default to Valkey but accept Redis if the customer pays.
AWS ElastiCache (Memcached engine), GCP Memorystore (Memcached). Quieter, but very stable.
memtier_benchmark, 32 client threads, 50/50 GET/SET, 10M keys, c5.4xlarge (16 vCPU). Single-instance Redis runs on one core; Memcached spreads across all 16; the cluster row shows Redis sharded across 6 nodes for matched parallelism. Numbers reproduced from the official memtier_benchmark README plus AWS's public Redis-vs-Memcached ElastiCache study.
Fronting a database with cached query results (pages, API responses)
Both work. The team that already operates one of them should keep doing so. Memcached is cheaper at the instance level; Redis preserves optionality.
Session store with TTL and atomic counters
INCR with EXPIRE on a single key, atomic. Hashes for session payloads. Persistence so a restart does not log everyone out.
Leaderboards, rate limiters, and real-time counts
ZADD and ZINCRBY on sorted sets match the shape of these problems exactly. Memcached has no path here.
Pure object cache fronting a CMS in a single hot region
Multi-threaded throughput, lower per-key memory overhead, BSD license. Pair with client-side consistent hashing.
Event streaming with consumer groups at sustained volume
Redis Streams works at small scale. At high volume, many consumers, or long retention, a real broker is the right tool.