Redis vs. Memcached: 300 Million Keys in 5 GB, Billions of Requests a Second

Redis vs. Memcached: 300 Million Keys in 5 GB, Billions of Requests a Second

Instagram once needed to keep a mapping of about 300 million photos back to the users who posted them. The obvious approach, one Redis key per photo, used about 70 MB for every million keys, which works out to roughly 21 GB for the full set. Their engineers asked one of Redis's core developers for advice, switched to packing the data into Redis hashes, and the same million keys dropped to 16 MB. The full 300 million fit in just under 5 GB, small enough for a much cheaper server, at about a third of the cost. Nothing about the data changed. They changed how it was stored.

Now look at the opposite end of the cache world. Facebook's memcache paper describes a system that handles billions of requests per second and holds trillions of items, and it notes that loading a single popular page averages 521 distinct memcache fetches. That's built on Memcached, a deliberately simple key-value cache with no fancy data types at all.

Both are in-memory caches, and both are famous in production. They embody opposite philosophies: Redis is a data structure server with a big toolbox, while Memcached is a small, fast cache that does one job. In 2026 there's a third wrinkle too. Redis changed its license in March 2024, the community responded with a fork called Valkey, and Redis added an open-source license option again in May 2025. This guide compares all of them honestly, explains where the real numbers come from, and shows how to choose without picking whichever one you saw in your last tutorial.

If caching is new to you, it helps to understand the databases it sits in front of; our PostgreSQL vs. MongoDB guide covers that, and our Backend Engineer and System Design courses build the foundation for this comparison.

This post originally appeared on the Ciphemic Academia blog.

The Short Version

• Memcached is a simple, multi-threaded, in-memory key-value cache. It stores strings or blobs under a key, expires them, and evicts the least recently used ones when memory fills. It has no persistence.
• Redis is an in-memory data structure server. Beyond plain values, it offers hashes, lists, sets, sorted sets, and streams, with optional persistence, replication, clustering, pub/sub, and scripting.
• Valkey is a BSD-licensed fork of Redis 7.2.4, created under the Linux Foundation after Redis's 2024 license change, and widely offered by cloud providers.

If you want one default: if you only need a cache for simple values and want maximum simplicity, Memcached is a legitimate, battle-tested choice. If you need data structures, persistence, atomic operations, or one tool for caching plus sessions, rate limiting, and leaderboards, pick a Redis-compatible store, and for managed cloud use compare what your provider offers. Most new projects end up in the second group.

What Both Are Actually Trying to Solve

Before the differences, the shared job:

• Cutting latency: reading from RAM over a fast network is far quicker than running the same database query again
• Protecting the database: a cache absorbs repeated reads so the database isn't hit for the same data thousands of times
• Handling expiry and eviction: hot data stays, old data expires, and memory never grows without limit
• Surviving the hard part, invalidation: a cache that serves stale data can be worse than no cache, and deciding when to refresh or delete entries is where most bugs live

Both are most often used in the cache-aside pattern:

def get_user(user_id):
    key = f"user:{user_id}"
    cached = cache.get(key)
    if cached is not None:
        return json.loads(cached)               # fast path: served from memory
    user = db.fetch_user(user_id)               # slow path: hit the database
    cache.set(key, json.dumps(user), ex=300)    # keep it for 5 minutes
    return user

(The ex=300 argument is redis-py's style. Memcached client libraries use a similar expiry argument under a different name.) Everything else in this post is about what each tool gives you beyond this basic loop.

Memcached

What it actually is: a distributed memory cache built around one idea: store an opaque value under a key, fast. It's multi-threaded, so a single server uses multiple CPU cores, and it manages memory with a slab allocator. There's no clustering built into the server itself; clients (or a proxy) decide which server holds which key, typically using consistent hashing.

A small example (the text protocol, set then get):

set user:42 0 300 12
alex-profile
STORED
get user:42
VALUE user:42 0 12
alex-profile
END

The numbers mean flags, expiry in seconds, and value size in bytes.

Where it shines:

• Simplicity: a tiny feature surface means fewer surprises, less to configure, and less to learn
• Multi-core throughput: a single node can use multiple threads for a high volume of simple gets and sets
• Proven at extreme scale: Facebook's paper describes a memcached-based system serving billions of requests per second over trillions of items
• Predictable behavior: it's a cache, so it expires and evicts by design and doesn't pretend to be a database

Where it struggles:

• Values are opaque strings or blobs: your application serializes and deserializes everything, and you can't operate on part of a value
• No persistence: a restart means a cold cache, and a sudden flood of misses can overwhelm the database. Facebook built dedicated mechanisms such as leases and cold-cluster handling to manage exactly this
• No built-in replication or failover: high availability and sharding are handled by client logic or extra tooling. Facebook wrote its own proxy, mcrouter, for routing at their scale
• Limited item size: items default to a 1 MB maximum, which is plenty for most cached objects but not for large blobs
• Fewer features: no data structures, pub/sub, or scripting

Who this suits: teams that want a plain, fast cache for database query results, rendered fragments, or session blobs, and want minimal operational surface.

Redis

What it actually is: an in-memory data structure server. Instead of just strings, values can be hashes, lists, sets, sorted sets, streams, and more, and you operate on them atomically on the server. It can persist data to disk (snapshots or an append-only log), replicate to other nodes, and shard across a cluster.

A small example (a cached profile as a hash, and a leaderboard as a sorted set):

HSET user:42 name "Alex" plan "pro"
EXPIRE user:42 300
HGETALL user:42

ZADD leaderboard 1520 "alex"
ZREVRANGE leaderboard 0 2 WITHSCORES

Where it shines:

• Data structures do real work: a leaderboard is a sorted set, a rate limiter is a counter with an expiry, and a work queue can be a list or a stream, all without extra code in your app
• Memory efficiency when used well: Instagram's hash trick cut their mapping from about 70 MB to 16 MB per million keys
• Durability options: optional persistence lets some deployments survive restarts with their data intact
• High availability and scaling built in: replication, automatic failover, and cluster sharding are first-class features
• One tool for many jobs: caching, sessions, pub/sub, queues, and counters can live in a single system, which some teams value and others see as a risk

Where it struggles:

• Core command execution is single-threaded: newer versions use extra threads for network I/O, but a single Redis process doesn't use many cores for command execution the way Memcached does, so scaling out usually means sharding
• More to operate: persistence, replication, and clustering each add settings, failure modes, and things to monitor
• Easy to misuse as a primary database: a fast in-memory store is tempting for data that should be durable, without a review of what a crash or eviction would lose
• Licensing churn: Redis moved from the BSD license to RSALv2/SSPLv1 on March 20, 2024, then added AGPLv3 as another option with Redis 8 in May 2025, which matters for some self-hosted and commercial uses

Who this suits: anyone who wants caching plus richer operations, such as sessions, leaderboards, rate limiting, queues, and pub/sub, in one place.

Valkey, the Third Option

What it actually is: a fork of Redis 7.2.4, the last BSD-licensed release, created under the Linux Foundation. It was announced on March 28, 2024, eight days after Redis's license change, with backing from AWS, Google Cloud, Oracle, Ericsson, and Snap. It keeps the BSD-3-Clause license and vendor-neutral governance.

Why it matters in 2026:

• Cloud providers offer it: AWS has launched ElastiCache for Valkey and MemoryDB for Valkey, priced below the equivalent Redis offerings, so check the current pricing page for your region
• Mostly familiar: it descends from Redis 7.2, so most commands and client libraries work as they do with Redis, though you should test your own workload and any Redis modules you rely on
• Redis responded: Redis 8 added AGPLv3 as a licensing option in May 2025, so the licensing picture is more open than it was in 2024

A practical rule of thumb: if you use a managed cloud service, the more relevant question is usually which offering your provider supports and prices well, not the license text. If you self-host or embed the software in a product you distribute, have the licenses reviewed by someone qualified, because AGPL and BSD carry very different obligations.

Side-by-Side Comparison

	Memcached	Redis
Data model	Opaque string/blob values	Strings, hashes, lists, sets, sorted sets, streams
Threading	Multi-threaded	Single-threaded command execution, extra I/O threads in newer versions
Persistence	None	Optional (snapshots, append-only log)
Replication and failover	Not built in	Built in
Sharding	Client-side, or via a proxy	Redis Cluster, built in
Default max item size	1 MB	String values up to 512 MB
Eviction	LRU	Multiple policies, including LRU and LFU
Extras	Minimal by design	Pub/sub, scripting, transactions, streams
Best for	Plain, high-volume caching	Caching plus richer operations
Licensing	BSD	RSALv2/SSPLv1/AGPLv3 (Redis 8+); Valkey is BSD
Famous example	Facebook's memcache	Instagram's photo-to-user mapping

How This Fits a Career Path

• Backend engineers: caching is a baseline skill. Cache-aside, TTLs, and invalidation come up in code reviews, incident postmortems, and nearly every system design interview
• Platform, SRE, and DevOps roles: you'll run these systems and watch hit rate, latency, and evictions; our logs vs. metrics vs. traces post shows how to build that visibility
• Full-stack engineers: sessions, rate limits, and cached API responses usually land in Redis-compatible stores
• System design interviews: be ready to say what you'd cache, how long, how you'd invalidate it, and why you'd choose one store over another for that workload, instead of just saying "add Redis"
• Messaging adjacency: Redis can act as a lightweight queue or stream, and our Kafka vs. RabbitMQ vs. SQS post covers when you need a dedicated broker instead

How to Choose Without Overthinking It

1. Start from what you're storing and what you need to do with it. Plain values with get and set point toward either; sorted lists, counters, and atomic operations point toward Redis.
2. Pick Memcached when the job is a simple cache and you want the smallest operational surface and multi-core throughput per node.
3. Pick a Redis-compatible store when you need data structures, persistence, pub/sub, or several jobs in one place. This is where most new projects land.
4. If you're on a managed cloud service, compare what your provider offers and charges for Valkey, Redis, and Memcached before deciding. Self-host only when you have a reason.
5. Whatever you choose, plan for invalidation and misses. Set TTLs, monitor hit rate and evictions, and make sure a cold cache can't flatten your database.
6. Don't treat it as either/or forever. Instagram's engineers described Redis powering its main feed and the photo mapping, and public accounts of its early stack also mention Memcached in front of its Django web layer, so real systems often mix tools.

A note on honesty: the Instagram figures come from a 2011 write-up about one specific data shape, and Redis's internals have changed since, so don't expect the same 70 MB to 16 MB ratio for your data. Test with your own keys. The Facebook numbers describe a scale most companies will never reach, so they show what Memcached can do, not what you need. And licensing and pricing are moving targets, so check each project's current license and your cloud provider's current price list before committing.

Common Mistakes When Learning Caching

• Treating the cache as the source of truth. A cache can evict or lose data. The authoritative copy lives in your database.
• Caching without an invalidation plan. Stale data bugs are subtle and expensive. Decide how entries get refreshed or deleted before you add the cache.
• Skipping TTLs. Keys without expiry fill memory and force evictions at the worst moments.
• Ignoring cache stampedes. When a popular key expires, thousands of requests can hit the database at once. Facebook's lease mechanism exists to prevent exactly that.
• Using Redis as a primary database without reviewing durability. Know what a restart, failover, or eviction would lose.
• Storing huge values. Large blobs hurt latency and memory; keep cached objects small.
• Picking by habit. Choosing Redis because everyone does, or Memcached because it's "simple," without checking what you actually need.
• Skipping the license check for self-hosted or distributed use. The 2024 changes mean the license genuinely matters in some situations.

Frequently Asked Questions

Which is faster, Redis or Memcached?

For simple gets and sets, both are very fast on a good network, and the differences depend heavily on your workload, value sizes, and configuration. Memcached uses multiple threads per node, while Redis typically scales by sharding. Benchmark your own access pattern rather than trusting a headline number.

Is Memcached obsolete now that Redis exists?

No. Facebook built an enormous caching system on it, and it remains a solid choice for plain caching. It's just a smaller tool, which is exactly what some teams want.

Should I use Redis or Valkey for a new project?

If you use a managed cloud service, compare what your provider supports and charges for each, since many now offer Valkey at lower prices. If you self-host, consider the license that suits your situation, and test that your clients and any modules work.

Can Redis replace Memcached?

Often yes for simple caching, since both support get, set, and expiry, but you take on Redis's extra operational features and its different threading model. Migrate deliberately and measure.

Should I store sessions in the cache?

It's a common use, and Redis-compatible stores are popular for it because of their persistence and replication options. Decide what should happen to logged-in users if the cache restarts, and design for that. Our JWT vs. Sessions post covers the trade-offs.

How do interviewers evaluate this topic?

Usually by asking you to design a cache for a specific system: what you'd store, how long, how you'd invalidate it, and what happens on a miss or a failure. Explaining the trade-offs, like Instagram's memory savings and Facebook's miss handling, matters more than naming a tool.

Measure Before You Choose

The real lesson from Instagram's 5 GB and Facebook's billions of requests isn't "Redis wins" or "Memcached wins." Both teams understood their own data and access patterns, then chose and tuned accordingly. Explore the Backend Engineer and System Design courses to build the skills that let you make that same evidence-based call on your own systems.