| Aspect | Redis | Memcached |
|---|---|---|
| Data model | Strings, hashes, lists, sets, sorted sets, streams, bitmaps | Only key and value (bytes) |
| Persistence | Yes: RDB snapshots and AOF log | None, the cache is empty after a restart |
| Threading | Command execution is single-threaded, I/O can be multi-threaded | Multi-threaded, scales across cores on one node |
| Clustering | Built-in Redis Cluster with sharding and replicas | Client-side sharding, no replication |
| Ops complexity | Higher: memory, persistence, failover | Low: install and forget |
| License | BSD up to 7.2, then RSALv2/SSPLv1, Redis 8 added AGPLv3; Valkey fork (BSD) | BSD-3-Clause |
| Ecosystem | Huge: queues, rate limiting, pub/sub, sessions, licensed modules | Narrow but stable and simple |
| Best for | Cache plus data structures, queues, counters, sessions | Pure high-volume cache with simple logic |
Choose Redis when
- You need more than strings: counters, leaderboards, queues, locks.
- The cache must survive a restart or you need a replica.
- You want one tool for cache, sessions and rate limiting.
Choose Memcached when
- You only need a simple cache of strings or serialized objects.
- Using all cores of one large node matters.
- You do not want to manage persistence and failover.
Bottom line
For most new projects pick Redis (or Valkey if the license matters): it covers caching and a lot more. Memcached remains a solid choice for a pure cache where simplicity wins.
Compared
Logos belong to their owners and are used for identification only. Icons: Simple Icons (CC0), Devicon (MIT).