Performance

Redis vs Memcached

PerformanceCachingDecision guide

Short answer

Choose Memcached for a disposable, simple key-value cache where horizontal sharding and low operational surface are the priority. Choose Redis when you need atomic counters, sets, sorted sets, streams, richer coordination, or controlled persistence; remember that Redis features can turn a cache into a stateful dependency.

Written and reviewed by Sahil Srivastav

What each one actually is

Memcached stores opaque values in memory with a simple get/set protocol. Clients commonly shard keys across nodes, and eviction or node loss means a cache miss.

Redis is an in-memory data store with strings, hashes, lists, sets, sorted sets, streams, scripts, and more. It supports atomic commands and optional persistence and replication, depending on the deployment.

Neither should be treated as the source of truth for data that cannot be rebuilt unless the durability and recovery contract is explicitly designed and tested.

Side by side

	Redis	Memcached
Data model	Key-value plus rich native types	Opaque key-value blobs
Atomic operations	Counters, conditional updates, scripts	Basic item operations and CAS
Persistence	RDB/AOF options and replication	Primarily disposable memory cache
Distribution	Cluster or client-side strategies	Usually client-side sharding
Eviction	Configurable policies and maxmemory	Slab allocator and item eviction
Use beyond cache	Queues, locks, rate limits, pub/sub	Best kept as a cache
Failure impact	Can lose state or block writes at maxmemory	Misses and stampede are the usual risk
Operational complexity	More features and persistence choices	Small surface and straightforward replacement

Choose Redis when

A cache miss is enough recovery and values are independent blobs
You want the simplest sharded cache with no durable state
The application already owns counters or coordination elsewhere
Low operational complexity matters more than server-side structures

Choose Memcached when

Atomic counters, sets, sorted rankings, or streams are required
A rate limiter, lock, or queue needs server-side atomicity
Controlled persistence or replication is part of the recovery plan
One data structure can avoid fetching and rewriting a large blob

The trade-off in detail

Redis is often selected for a cache and then quietly becomes the database for sessions, locks, queues, and counters. Every such use needs a durability, failover, and overload policy; when maxmemory is reached, writes may fail depending on the configured policy.

Memcached’s simplicity is a feature only when the application tolerates misses. A node failure can invalidate a large shard and create a database stampede, so use TTL jitter, request coalescing, and bounded rebuild concurrency.

Redis cluster hashing means multi-key operations generally need keys in the same hash slot. Designing key tags early can avoid CROSSSLOT failures, but over-concentrating hot keys creates a different bottleneck.

Things that are commonly said and are wrong

“Redis is always durable.” Persistence settings and acknowledged replication affect loss windows; a running Redis process is not a backup.
“Memcached is always faster.” Workload, payload size, network, and command choice decide latency.
“A cache lock makes a critical operation safe.” Lease expiry and client pauses can let two owners proceed; protect the underlying invariant too.

Decide it in a real repository

Choosing correctly on a whiteboard and enforcing the choice in code are different skills. Gronex ships broken backend repositories whose tests assert the invariant, not the happy path.

FAQ

Which is better for a normal web cache?

Memcached is a good default when values are disposable and simple. Redis is a good choice when atomic counters, structured values, or shared coordination are already required.

Can Redis replace a database?

Only for a deliberately designed workload with an explicit persistence and recovery plan. Treating a cache with accidental state as a database leaves data loss and migration risks hidden.

Why did Redis start rejecting writes?

With a maxmemory limit and a no-eviction policy, Redis returns an OOM error when it cannot free enough memory. Inspect memory usage and eviction policy; increasing the limit without capacity planning only delays the failure.