Redis vs Memcached vs Valkey: The Full Feature Comparison (2026)
Redis 8.0 vs Memcached 1.6.x vs Valkey 8.1. Every row sourced against current docs.
| Feature | Memcached 1.6.x | Redis 8.0 | Valkey 8.1 |
|---|---|---|---|
| License | BSD-3-Clause | RSALv2 / SSPLv1 / AGPLv3 | BSD-3-Clause |
| Current version | 1.6.x | 8.0.x | 8.1.x |
| Data types | Strings only | 12+ types: strings, lists, sets, sorted sets, hashes, bitmaps, hyperloglogs, streams, geospatial, JSON, vector sets | 10+ types (Redis 7.2 baseline); no vector sets yet |
| Persistence | None (restart wipes all data) | RDB snapshots + AOF write-ahead log | RDB + AOF (same as Redis) |
| Replication | None (client-side sharding only) | Async master-replica | Async master-replica (Redis-compatible) |
| Clustering | Client-side sharding only | Redis Cluster (16,384 hash slots) | Cluster mode (Redis Cluster-compatible) |
| Pub/sub | No | Yes (SUBSCRIBE / PUBLISH, fire-and-forget) | Yes (equivalent to Redis 7.2) |
| Streams (consumer groups) | No | Yes (XADD, XREAD, XGROUP) | Yes |
| Threading model | Multi-threaded (since v1.4) | Single event-loop + optional I/O threads | Multi-threaded I/O (redesigned in 8.0) |
| Memory model | Slab allocator, fixed-size classes | jemalloc, flexible allocation | jemalloc, flexible |
| Eviction policies | LRU only | 8 policies: LRU, LFU, volatile-TTL, random, etc. | 8 policies (same as Redis) |
| TLS | No native TLS (network-level only) | Yes (native TLS) | Yes |
| ACLs / auth | SASL only | Full ACL system (per-command, per-key-pattern) | Full ACL system |
| Hash field TTL | No (no hashes) | Yes (HEXPIRE, Redis 8.0) | In development (not in 8.1) |
| Vector search | No | Yes (vector sets, HNSW, Redis 8.0) | Not yet (early 2026) |
| Active development | Yes | Yes | Yes |
Sources: memcached.org, redis.io, valkey.io. Verified May 2026.
Data types: why Memcached's strings-only is not a bug
Memcached's design constraint of strings-only forces application-side serialisation. For HTML page caches and simple ephemeral lookups, this is fine and even preferable: less surface area, simpler protocol, lower per-item overhead. Redis gives you 12+ native data types: strings, lists, sets, sorted sets (ZADD/ZREVRANGE for leaderboards), hashes (HSET/HGETALL for sessions and objects), bitmaps (bitfield analytics), hyperloglogs (approximate cardinality), streams (XADD/XREAD for event logs), geospatial (GEOADD/GEORADIUS), JSON (RedisJSON module), and as of May 2025, vector sets (VADD/VSIM for AI/RAG). Valkey covers the Redis 7.2.4 baseline (all types except vector sets and hash field TTL).
Persistence: the line that separates cache from session store
Memcached has zero persistence. Process restart wipes all data. By design: Memcached is a cache, not a database. If you need persistence, that is the signal to use Redis or Valkey. Redis offers two mechanisms: RDB (point-in-time snapshots at configurable intervals) and AOF (append-only file, write-ahead log for full durability). Valkey implements both identically. The practical implication: do not store sessions, rate-limit counters, or any data you cannot regenerate in Memcached. Source: redis.io/docs/management/persistence/
Replication and clustering
Memcached has no built-in replication. Clustering is client-side sharding: your application code or a client library decides which Memcached node holds which key. A node failure means data loss for that shard. Redis Cluster handles slot-based sharding across up to 16,384 hash slots with automatic failover and master-replica replication. Valkey is Redis Cluster-compatible and supports the same slot-sharding model. For production deployments where data availability matters (sessions, rate limiters, leaderboards), Redis or Valkey cluster mode is required.
Threading: Memcached's quiet edge
Memcached has been multi-threaded since v1.4 (around 2009). It distributes incoming connections across worker threads, making full use of multi-core CPUs. Redis uses a single-threaded event loop for command execution with optional I/O threads (enabled via io-threads in redis.conf). Valkey 8.0 redesigned threading for parallel I/O dispatch, delivering 30-35% throughput improvement on multi-core instances (Better Stack 2026, independent benchmark). The practical result: Memcached still wins raw GET/SET at high concurrency on multi-core boxes (DevGenius 2026: ~20-25% edge). Valkey closes the gap on threading vs Redis but Memcached remains competitive on simple workloads.
Eviction policies
Memcached offers LRU (Least Recently Used) only. Redis and Valkey offer eight eviction policies: allkeys-lru, allkeys-lfu (Least Frequently Used), allkeys-random, volatile-lru (LRU on keys with TTL set), volatile-lfu, volatile-ttl (TTL-based priority), volatile-random, and noeviction. For caches with long-tail access patterns (most items accessed once, a minority accessed frequently), LFU significantly outperforms LRU by preserving popular items. Memcached's LRU-only policy is a real constraint at scale.
Security
Memcached requires network-level security (VPC isolation, firewall rules). It supports SASL authentication but no native TLS and no per-command access control. Redis and Valkey both offer native TLS (configured in redis.conf/valkey.conf), full ACL systems (ACL SETUSER, per-command and per-key-pattern permissions), and password authentication. Enterprise environments that require in-transit encryption or granular access control effectively require Redis or Valkey. Memcached in a private subnet is standard in Facebook-scale deployments but requires network trust.
Memcached in 2026: still maintained, still used
Memcached 1.6.x is actively developed in 2026. Released in 2003, BSD-licensed, no license changes, no commercial entity drama. It is used in production by Facebook (the world's largest Memcached deployment, documented in the 2013 NSDI paper 'Scaling Memcache at Facebook' by Nishtala et al.), Wikipedia, YouTube, Twitter (legacy), LiveJournal. Less hyped than Redis since 2010, but not deprecated. The realistic Memcached use case in 2026: HTML page caching, simple ephemeral API response caching, or any workload where you genuinely need BSD permissiveness and multi-threaded raw throughput without structured data. It is a narrow lane, but a real one.
What this means for your decision
If your only requirement is a fast, ephemeral, simple cache (HTML pages, API responses, no structured data), Memcached is a legitimate choice in 2026. If you need anything beyond that (sessions, pub/sub, sorted sets, persistence, replication, security beyond network-trust), Redis or Valkey is the answer. The license question then determines which of the two.