Redis and Memcached are both in-memory key-value stores optimized for microsecond read latency. Memcached was designed for one job — caching — and does it well. Redis started as a cache and grew into a data structure server with persistence, pub/sub, streams, probabilistic data structures, and a scripting engine. In 2026, choosing between them is mostly a question of whether you want a purpose-built cache or a flexible in-memory data layer.
What changed in 2026
- Redis 7.x ships Redis Functions. Lua scripting is joined by Redis Functions (server-side Lua/JavaScript modules), making complex atomic operations easier to maintain than raw Lua scripts.
- Valkey forked and gained traction. Valkey is the Linux Foundation fork of Redis created after Redis changed its license to RSAL/SSPL in 2024. Valkey 7.x is a drop-in Redis replacement maintained by AWS, Google, and others. It is the open-source default on many managed platforms now.
- Memcached 1.6.x added TLS and extstore. Extstore allows Memcached to spill to NVMe SSDs while keeping hot data in RAM — a legitimate architectural improvement for very large caches.
- Upstash Redis and AWS ElastiCache Serverless emerged as the dominant managed Redis options, with per-request pricing that makes Redis viable for serverless and edge workloads.
Core comparison
| Dimension |
Redis 7 / Valkey |
Memcached 1.6 |
| Data structures |
Strings, hashes, lists, sets, sorted sets, streams, HyperLogLog, geospatial |
Strings only |
| Persistence |
RDB snapshots + AOF |
None |
| Replication |
Master-replica + Cluster |
None built-in |
| Pub/sub |
Yes (pub/sub + streams) |
No |
| Transactions |
MULTI/EXEC (optimistic) |
No |
| Lua scripting |
Yes |
No |
| Multi-threaded |
No (I/O threads optional) |
Yes |
| Max value size |
512 MB |
1 MB |
| License |
SSPL (Redis) / BSD (Valkey) |
BSD |
| Managed options |
Upstash, Redis Cloud, ElastiCache |
ElastiCache |
Performance reality
# Benchmark: redis-benchmark vs memtier (single-node, r7g.xlarge)
# GET operations, 100 byte values, 50 parallel connections
Redis 7.2: ~800,000 ops/sec
Memcached 1.6: ~1,100,000 ops/sec (4 cores utilized)
Valkey 7.2: ~820,000 ops/sec
Memcached's multi-threaded architecture uses all CPU cores, giving it a throughput edge on multi-core machines for pure string GET/SET workloads. Redis's I/O thread mode (enabled via io-threads config) narrows but does not close the gap.
For most applications, both are far faster than any network or database I/O they are caching — the difference between 800K and 1.1M ops/sec does not matter when your downstream database handles 5K queries/sec.
Redis data structure use cases
# Redis sorted set — real-time leaderboard
import redis
r = redis.Redis()
# Update score (atomic, O(log N))
r.zadd("leaderboard:week", {"user:42": 1500})
# Top 10 players with scores
top10 = r.zrevrange("leaderboard:week", 0, 9, withscores=True)
# Redis streams — event log with consumer groups
# Producer
r.xadd("events", {"type": "purchase", "userId": "42", "amount": "99.99"})
# Consumer group (at-least-once delivery)
r.xgroup_create("events", "analytics", id="0", mkstream=True)
messages = r.xreadgroup("analytics", "worker-1", {"events": ">"}, count=10)
These patterns — leaderboards, rate limiters, session storage, distributed locks, event streams — require Redis and are awkward or impossible with Memcached.
How to pick
- Pure caching of database query results or rendered pages? Either works. Pick Redis/Valkey for the future flexibility; pick Memcached if you have an existing operational investment.
- Session storage? Redis — TTL support, data structure flexibility, and replication make it the standard for session management.
- Rate limiting? Redis — atomic increment and TTL with
INCR/EXPIRE is the canonical approach.
- Pub/sub messaging or event streams? Redis Streams or pub/sub. Memcached has no equivalent.
- Multi-threaded cache at maximum throughput with no other needs? Memcached — it edges out Redis on pure cache throughput at high core counts.
- Open-source licensing matters? Choose Valkey — it is the BSD-licensed drop-in Redis alternative.
Common mistakes
Using Redis without persistence for session data. If your Redis instance restarts and all sessions are lost, users get logged out. Enable AOF or use a managed provider with durability guarantees for session stores.
Not setting TTLs on cached keys. Redis will fill memory and start evicting random keys if you forget TTLs. Always set EXPIRE or use SET ... EX for cache keys.
Using Redis pub/sub for durable messaging. Redis pub/sub is fire-and-forget — messages sent while a consumer is down are lost. Use Redis Streams with consumer groups, or a proper message broker like Kafka, for durability.
Choosing Memcached and then later needing pub/sub. This is the most common regret. Memcached is fast but a dead end if your needs grow.
What to skip
- Rolling your own in-memory cache in application code for anything shared across processes or machines. Redis is the right tool.
- Redis as a primary database for critical data — Redis persistence (AOF) works, but it is not a substitute for Postgres for relational, ACID-critical data.
- Redis Cluster without careful keyslot planning — all keys in a multi-key operation must be in the same hash slot. Use hash tags
{user:42} consistently.
FAQ
Is Valkey a safe drop-in for Redis?
Yes. Valkey 7.x is protocol-compatible with Redis 7.x. Managed providers including AWS ElastiCache and Aiven have migrated their Redis offerings to Valkey. The switch is transparent for most clients.
Should I use Redis for a message queue instead of Kafka or RabbitMQ?
Redis Streams are viable for moderate-throughput event queues (< ~100K messages/sec) with durable delivery needs. For high-throughput event streaming with long retention, Kafka is better. For complex routing, use RabbitMQ.
What is the Redis memory eviction policy I should use?
For a cache, use allkeys-lru or allkeys-lfu. allkeys-lru evicts least-recently-used keys when memory fills; lfu evicts least-frequently-used. Never use noeviction for a cache — it causes write failures under memory pressure.
How do I cache API responses in practice?
See How to cache API responses in 2026 for a step-by-step guide.
Where to go next