Overview
Redis and Memcached are the two canonical in-memory stores, and for the narrow job of "cache this string under this key with a TTL," they are interchangeable, both answer in sub-millisecond time. The confusion comes from treating them as competitors at the same scope. Memcached is deliberately just a cache: a multithreaded LRU key-value store for opaque blobs, with nothing else on purpose. Redis is an in-memory data-structure server: lists, hashes, sets, sorted sets, and streams as first-class types, plus persistence, replication, transactions, Lua scripting, and pub/sub, a cache that can also be a queue, a leaderboard, a rate limiter, or a session store with real durability options.
Feature comparison
| Redis | Memcached | |
|---|---|---|
| Data types | Strings, lists, hashes, sets, sorted sets, streams, bitmaps, HyperLogLog, geospatial | Opaque byte blobs only |
| Persistence | RDB snapshots and AOF journaling, configurable | None; restart means an empty cache |
| Replication / HA | Built-in replication, Sentinel failover, Redis Cluster sharding | None built in; clients shard across independent nodes |
| Threading | Single-threaded command execution (I/O threading for network work) | Fully multithreaded; one instance scales across cores |
| Atomic operations | Rich; per-type commands, MULTI/EXEC transactions, Lua scripts | Increment/decrement, append, CAS |
| Eviction | Multiple policies (LRU, LFU, TTL-based, none) | Slab-allocated LRU |
| Pub/sub and streams | Built in | No |
| Memory overflow to disk | No (RAM-bound) | Optional extstore extension pushes cold values to SSD |
| License | Tri-license since Redis 8: AGPLv3, RSALv2, or SSPLv1 (BSD fork: Valkey) | BSD |
| Operational surface | Larger; more features, more configuration | Minimal; a handful of flags |
Where Memcached tends to win
Pure, high-volume caching. Its multithreaded design means one big instance can use every core on the box, where a single Redis process serializes command execution on one thread, and its slab allocator is efficient and predictable for millions of small, flat objects like rendered fragments or session blobs. There's almost nothing to configure, tune, or upgrade carefully, and client-side consistent hashing across independent nodes is a simple, well-worn scaling story. If every value you store is a string and every access is get/set, Memcached does exactly that job with less machinery.
Where Redis tends to win
Everything beyond get/set. A sorted set gives you a leaderboard or a sliding-window rate limiter in one command; a list or stream gives you a work queue; atomic hash operations update one field of a cached object without a read-modify-write race. Persistence and replication mean a restart doesn't stampede your database with cold-cache misses, and Redis Cluster provides server-side sharding and failover without client gymnastics. If you're caching today but will need "cache plus a little state" tomorrow, sessions, counters, locks, queues, Redis means one system instead of two.
Note
Licensing changed in 2024: Redis moved from BSD to source-available licenses, then added AGPLv3 back as an option with Redis 8. Organizations that need a permissively licensed drop-in should look at Valkey, the Linux Foundation fork that continued from Redis 7.2 under BSD, protocol- and API-compatible for the common cases.
Verdict
Default to Redis; its data structures, persistence, and HA story cover far more ground, and for typical caching workloads its performance is more than sufficient. Choose Memcached when the job really is only ephemeral caching of flat values at very high request rates, and you want maximum throughput per node with minimum operational thought. The mistake to avoid is picking Memcached for simplicity and then rebuilding queues, counters, and locks in application code that Redis would have given you in one command each.