Redis vs Memcached: Which Cache Should You Use?

Redis and Memcached are the two standard answers to the same question: where do I put data that is too expensive to fetch on every request? Both are open-source, in-memory key-value stores with sub-millisecond reads, and both have been battle-tested at enormous scale. The difference is philosophy. Memcached is a pure cache — deliberately minimal and excellent at exactly one job. Redis is a data-structure server that also happens to be a superb cache. If all you need is “store this blob under this key for a while,” either works. The moment you need anything more, Redis wins by default.

Two tools, two philosophies

Memcached arrived in 2003, built by Brad Fitzpatrick to take load off LiveJournal’s databases. Its design has barely changed since, and that is the point: it stores opaque byte blobs under string keys, evicts the least recently used items when memory fills, and does nothing else. There is almost nothing to configure and almost nothing that can surprise you.

Redis arrived in 2009 with a broader ambition. Instead of opaque blobs, values are typed data structures — hashes, lists, sets, sorted sets, streams — with commands that operate on them server-side. Increment a counter, pop a job off a queue, or fetch the top ten of a leaderboard without ever pulling the whole value across the network. Add persistence, replication, and pub/sub, and Redis stops being just a cache and becomes a general-purpose data infrastructure component.

Feature comparison

	Redis	Memcached
Values	Typed structures: strings, hashes, lists, sets, sorted sets, streams	Opaque byte blobs
Persistence	RDB snapshots and/or AOF log	None — restart means an empty cache
Replication & HA	Built-in replicas, Sentinel, Redis Cluster	None built-in; clients shard across nodes
Threading	Single-threaded commands, I/O threads for networking	Fully multithreaded
Eviction	Multiple policies: LRU, LFU, TTL-only, no-eviction	LRU
Pub/sub & queues	Yes	No
Max value size	512 MB	1 MB by default
Server-side scripting	Lua	No

The threading difference

This is the most interesting technical divergence. Memcached is fully multithreaded: one process saturates every core on the machine, so a single large instance can serve enormous request volumes. Redis executes commands on a single thread. That sounds like a limitation, but it is a deliberate trade — every command runs atomically with no locks, which is precisely what makes patterns like atomic counters and check-and-set operations safe. Redis 6 added I/O threads so network reads and writes can parallelize, but command execution remains sequential.

In practice this means Memcached scales up (add cores to one box) while Redis scales out (run more instances, or use Redis Cluster to shard keys across nodes). For most applications the single Redis thread is nowhere near the bottleneck — the network is — but at extreme cache-only throughput on big multi-core machines, Memcached’s model is genuinely more efficient.

When Memcached still wins

• Pure ephemeral caching at very high throughput. If the workload is purely GET/SET of small blobs and you have big multi-core machines, Memcached extracts more from each box.
• Predictable memory behavior. Memcached’s slab allocator avoids the fragmentation questions that come with long-running Redis instances holding varied value sizes.
• Operational simplicity. There are no persistence settings, eviction policies, or replication topologies to reason about. A Memcached node that dies is just a cold cache, never lost data — because there was never data to lose.

That last point cuts both ways. Memcached is simple because it refuses to be anything but a cache, and that refusal is only a virtue if a cache is all you need.

When Redis wins

Almost every other time. The data structures alone cover a remarkable range of problems beyond plain caching: sorted sets for leaderboards, lists and streams for job queues, atomic counters for rate limiting, hashes for session objects. Persistence means sessions and queues survive a restart. Replication and Sentinel give you high availability that Memcached simply does not offer. Pub/sub handles lightweight real-time messaging without adding another piece of infrastructure.

There is also an ecosystem argument. Nearly every framework, platform, and managed-hosting provider treats Redis as the default cache and session store, so the paved path is wider — client libraries are richer, and patterns are better documented. If you want to understand how it works from the inside, building a minimal Redis clone is one of the most instructive weekend projects in systems programming.

The license wrinkle

One recent complication worth knowing: in 2024, Redis moved from the permissive BSD license to a source-available dual license, and the community responded by forking the last BSD version as Valkey under the Linux Foundation, with backing from AWS, Google, and other major operators. Valkey is protocol-compatible and a drop-in replacement, and in 2025 Redis itself added the open-source AGPL back as a licensing option. For an application developer the day-to-day difference is nil — same commands, same clients — but if permissive open governance matters to your organization, Valkey is the answer, and cloud providers increasingly offer it under their managed-cache products.

Migrating between them

Because most caching is cache-aside — the application checks the cache, and falls back to a database like PostgreSQL on a miss — migrating is unusually low-risk: point the application at the new cache and let it warm up. The main cost is a temporary spike in database load while the hit ratio recovers, so migrate during low traffic or warm the new cache first. Going from Memcached to Redis is the common direction and mostly a client-library swap; going the other way requires giving up any Redis features beyond GET/SET, which is exactly the audit worth doing before you switch.

The takeaway

Default to Redis. It does everything Memcached does, plus data structures, persistence, replication, and messaging, and it is the assumed standard across the modern stack. Choose Memcached for the narrow case it was built for — a maximally simple, multithreaded, ephemeral cache pushing extreme throughput on multi-core hardware — and enjoy how little there is to operate. And whichever you pick, remember that the cache is an optimization, not a source of truth: the database behind it still owns the data.