You need a server-side cache, you've read two comparison pages, and both told you it depends. Helpful. So let's settle the Redis vs Memcached question up front: Memcached is the better fit when you want a plain, fast cache and nothing more, and Redis is the better fit when the cache has to hold structured data, survive a restart, or take work off your application's hands.
Both Redis and Memcached are:
That shared list is where most articles stop. This one carries on, because the interesting differences start after it.
Both store data in memory to make applications faster. They just aim at different problems.
Memcached is simple. It offers basic key-value storage and excels at caching data quickly, thanks to its multi-threaded performance.
Redis supports more complex data types and permanent data storage, which makes it versatile across a broader range of tasks such as messaging and session management. It also brings advanced options like data sharding, which is splitting a dataset across several servers so no single machine holds all of it, and a choice of eviction policies.
Based on a project we developed for a client, I'm going to cover how they handle data storage, scalability and which one performs better in which scenarios. First, the basics.
Redis, which means Remote Dictionary Server, was created in 2009 by Salvatore Sanfilippo, to improve the scalability of the web log analyser his Italian startup was building. The first prototype was written in Tcl and later transcribed to C. When Sanfilippo open sourced the project, it started to get some traction. GitHub and Instagram were among the first companies to adopt it, and the project's own documentation is still the reference for its behaviour and limits.
Memcached arrived a bit earlier, in 2003, built by Brad Fitzpatrick for his LiveJournal website. It was initially developed in Perl and then translated into C. Some of the largest companies in the world use it, including Facebook, YouTube and Twitter, and its behaviour is documented in the Memcached wiki.
Redis isn't really a key-value store; it's a data-structures server. The five you'll reach for most:
Beyond those it also ships bitmaps, bitfields, HyperLogLogs (probabilistic cardinality counters) and geospatial indexes, plus streams for append-only logs. JSON, querying, time series and — from Redis 8 — vector sets come in via modules (Redis data types documentation). It's a long way from "keys and strings," and that breadth is the whole reason Redis earns its keep in places a plain cache can't reach.
Redis supports data type operations, which means you can read or change part of an object without loading the whole thing into your application, editing it and storing it back.
For memory management it uses an encapsulated version of malloc/free, the standard C mechanism for requesting and releasing memory. Simpler than the Memcached Slab mechanism, which I'll come to below.
Keys can be up to 512MB, and so can values, as set out in its data types documentation. On aggregate data types such as Lists and Sets, that limit applies per element.
Memcached has no data types. It stores strings indexed by a string key, and it carries less overhead memory than Redis for the privilege.
It is also limited by the memory of the machine it sits on. When that fills up, it starts purging values in least recently used order. Its allocation mechanism, Slab, segments memory into chunks of different sizes and stores each key-value record in the chunk that fits. That is what keeps memory from fragmenting into gaps too small to reuse.
Keys top out at 250B and values at 1MB. Those are defaults, though, and you can raise the maximum slab size at startup (see the Memcached wiki).
Think of a cached object as a coat handed to a cloakroom. With Memcached you can only collect the whole coat: to change what's in one pocket, the string has to be loaded, deserialised, the field edited, serialised and stored again.
Redis lets you reach into the pocket. The hash data type gives you access to each field individually, so any CRUD (create, read, update, delete) operation runs against that field alone. One network round trip, about the cost of a plain get or set, replacing four exchanges and two serialisation steps.
Here's the same session update both ways:
# Memcached — the whole session object is the unit of work
value = mc.get("session:42") # 1. fetch the whole blob
session = deserialise(value) # 2. deserialise in app memory
session["last_seen"] = now() # 3. edit one field
mc.set("session:42", serialise(session)) # 4. serialise + write it all back
# → 2 network round trips, 2 (de)serialisation steps, in your app code
# Redis — the field is the unit of work
HSET session:42 last_seen <now> # one round trip, no (de)serialisation
# → the read-modify-write collapses into a single command on the serverThe reason this works is not specific to our project. Redis's own documentation and independent benchmarks show that cutting network round trips, rather than speeding up commands, is what moves throughput — see the performance section below for the numbers.
Redis is predominantly single-threaded, meaning one core executes the commands no matter how many the machine has. (Threaded I/O arrived in Redis 6, and Redis 8 and the Valkey fork have pushed I/O multithreading further — but the commands themselves still run on one thread; AWS notes the same single-threaded-with-I/O-multithreading distinction in its ElastiCache engine comparison.) With native clustering support, it grows well horizontally instead.
Clustering works on a master/slave architecture, where one node accepts writes and the others hold copies of its data. Every master has two slaves for redundancy, so if the master fails the system promotes one of them automatically. The cost is upkeep: several nodes running synchronously are harder to keep healthy than one.
Memcached scales vertically with ease, because it is multithreaded. Give it more cores and more memory, and that's the job done.
It scales horizontally too, on the client side, through a distributed algorithm you implement. More work than Redis, which ships clustering out of the box.
The biggest split between these two is what survives a restart. Redis is an in-memory (mostly) data store and it is not volatile. Memcached is an in-memory cache and it is volatile: restart the process and the contents are gone.
Redis supports persistence, which is why it is called a data store, in two ways (Redis persistence documentation):
A child process handles these files, and that detail decides which one you want.
Is a big dataset a problem? For RDB, yes. The file takes time to create, which shows up in response times, although it loads faster on boot than the AOF log does.
Choose AOF when losing data is not acceptable at all. It can be updated on every command and, being append-only, has no corruption issues. It also grows much larger than an RDB snapshot.
Nothing, by design. No snapshot, no log. A restart, a crash or a failover starts from an empty cache, and the first wave of requests after it falls straight through to the database.
That is fine when the cache holds derived data that is cheap to recompute. It becomes a capacity planning problem when it isn't.
Memcached is limited to the LRU (least recently used) eviction policy, whilst Redis supports eight (Redis key eviction documentation):
What that buys you is control. With Memcached, the LRU decides and you live with it. With Redis, you can protect the keys that must not vanish and let everything else be evicted around them.
This is usually where comparison pages swap evidence for assertion. Let's use numbers instead.
Redis publishes its own throughput figures. Its benchmark documentation reports that an entry-level Linux server running a single Redis instance handles in the order of 100,000 requests per second with small payloads, at sub-millisecond latency on a local network. That ceiling belongs to one core. Command execution is single-threaded, so adding cores to the machine does not lift it. Redis 6 added threaded I/O, which parallelises socket reads and writes, but the commands themselves still run on one thread.
Memcached is multithreaded end to end, so its throughput climbs with the core count until the network interface saturates. That is the whole of its performance advantage, and it is a genuine one: on a many-core machine serving large, simple values, Memcached moves more data per second than a single Redis process can. It is why AWS documents the two differently even inside the same managed service — its own whitepaper notes Memcached "makes good use of larger [instance] sizes with multiple cores," while Redis is managed more like a stateful database (Memcached vs. Redis: Performance at Scale with Amazon ElastiCache).
Two qualifications matter more than the headline figures. First, a Redis deployment is rarely one process, and sharding across instances wins back the multi-core advantage at the price of cluster upkeep. Second, operations per second is the wrong yardstick when one Redis command replaces several application round trips. A hash field update is one network exchange where Memcached needs a read, a deserialisation, a write and a serialisation. Redis can be slower per operation and still finish first.
This isn't only our own experience talking; the mechanism is documented and measurable. Because every command is a network round trip, it's the round-trip time — not command execution — that usually bounds throughput. Redis's own pipelining guide makes the point starkly: on a link with 250 ms round-trip time, a server capable of 100,000 requests per second is still throttled to roughly four per second until you stop paying for a round trip per command. Independent benchmarking shows the size of the prize: in a widely cited test run on DigitalOcean infrastructure, collapsing round trips took a stock redis-benchmark from about 97,000 GET/s to roughly 1.35 million GET/s — a ~14× gain that came entirely from removing network exchanges, not from faster commands. That is the same lever our session-object change pulled, in a different form: one hash command in place of a read, a deserialise, an edit, a serialise and a write. (Pipelining batches many commands; the hash type collapses one read-modify-write — different techniques, identical principle: fewer trips over the wire.)
The rule, then. Memcached for a high volume of independent reads of whole values on a large machine. Redis where the shape of the data lets you do fewer, smarter operations.
Three situations justify the operational cost, and they share a thread: the cache is doing something your application servers would otherwise do.
Memcached fits when the cache is genuinely a cache: values written whole, read whole, and safe to lose.
Here is the part that rarely makes it onto a comparison page. We call it the exit-cost test: before you choose a cache, ask what it would cost to leave it. The two answers are not symmetrical.
At Imaginary Cloud we have used both across many different client projects. On one I was involved in, we had to pick between them. We started with Memcached for its simplicity, ease of use and easy setup, and because we simply needed a cache, so persistence wasn't a requirement. After some testing, we swapped to Redis for the advantages of having data types.
The data type operations suited the kind of data we were storing. Redis also provides a command to search for keys matching a pattern, along with many other commands for working with keys, and that turned out to be the capability we kept reaching for. It was the deciding factor in migrating.
The migration itself was straightforward, since Redis supports most of the commands Memcached does. Repoint the client, let the cache refill, carry on.
Going the other way is a different story. Memcached has no data types, so every Redis data type command has to be translated into several Memcached commands with data processing in between to reach the same result. That logic lands back in the application code you moved it out of.
That asymmetry is the test. Start on Memcached and you keep a cheap exit to Redis. Start on Redis, discover you only ever needed a plain cache, and you're rewriting application logic to get back. When the requirements are genuinely uncertain, exit cost deserves more weight than any benchmark.
Redis is more flexible and more capable. Memcached still serves some purposes very well and in some cases performs better, because multi-threading pays off when you're moving large volumes of simple data.
Redis supports data operations thanks to its data types, and those reduce both the network I/O counts and the data sizes involved. A hash field update costs about what a plain get or set costs, so the work leaves your application without costing extra time on the wire.
So, a winner? No, of course not. Apply the performance rule, then the exit-cost test. Memcached for a high volume of independent reads of whole values on a large machine. Redis where the shape of the data lets you do fewer, smarter operations. When the two sit close together, take the one that is cheaper to leave. In our experience, weighing those pros and cons at the start is what spares you a migration halfway through the project.
If you're signing off the architecture rather than writing it, the technical comparison collapses into three commercial questions. We run these on every infrastructure and stack choice, not just caching.
1. What does it cost to run? Memcached carries lower memory overhead per item, so the same working set fits in a smaller instance. Redis costs more per gigabyte cached once persistence and replication are on, because an RDB snapshot needs headroom for the forked child process and a replicated cluster multiplies the instance count. Small difference at a few gigabytes. Material at a few hundred.
2. Who owns it on Monday morning? A single Memcached instance is close to zero maintenance. A Redis cluster with master and replica nodes, failover and persistence tuning is a system somebody has to own: monitor it, test the failover, size the snapshot window. If that person doesn't exist on your team, the honest options are a managed service or Memcached. ElastiCache or MemoryDB move the work to the provider and put it on the invoice instead, which is usually the right trade for a small team.
3. What is the licensing and continuity exposure? In March 2024 Redis moved from the BSD licence to a source-available dual model (RSALv2 and SSPLv1), which prompted the Linux Foundation to fork the last BSD release (7.2.4) as Valkey. In May 2025, Redis 8 added AGPLv3 — an OSI-approved open-source licence — alongside the source-available options, so Redis now ships under a tri-licence again, and Salvatore Sanfilippo had rejoined the company the year before. The fork stuck all the same: AWS itself flags that Redis 8.0 Community Edition is AGPLv3 (a copyleft many organisations disallow) while Memcached stays BSD, and now recommends Valkey for new ElastiCache workloads (AWS: Compare Redis and Memcached). The episode is a reminder that Redis is a dependency with a commercial owner and a licence that has already changed under pressure. Memcached has been BSD throughout with no such history. For most teams that isn't a blocker. For anyone embedding a cache in a product they redistribute — where the AGPL copyleft clause bites — it's a question to answer before the code is written, and Valkey is the permissive escape hatch worth knowing about.
Time-to-value usually favours starting simple. Memcached is faster to stand up, and as the exit-cost test shows, moving to Redis later is inexpensive. The reverse is not.
Not universally. On small values, per operation, they are close, and Redis publishes throughput of around 100,000 requests per second for a single instance on entry-level hardware. Memcached is multithreaded, so on a many-core machine serving large, simple values it shifts more data per second. Redis wins where its data types replace several application round trips with one command.
Yes, when the requirement really is a cache. Transient data, plain values, no persistence needed, cores to spare: Memcached is simpler to run, cheaper in memory overhead and has almost no operational surface.
Yes, and it is the easier direction, which is the whole point of the exit-cost test. Redis supports most of the commands Memcached does, so in practice you repoint the client and let the cache refill. Going the other way means rewriting data type operations as several Memcached commands plus application-side processing.
No. Memcached is a volatile in-memory cache: restart it and the contents are gone. Redis persists through RDB snapshots, point-in-time dumps to disk, or an AOF log that replays every write command on startup.
Memcached, on the infrastructure line, thanks to lower memory overhead per item and single-instance simplicity. Redis usually costs more once replication and persistence are enabled. The sums change if Redis takes work off your application servers or your database, since that saving can outweigh the difference in cache spend.
Redis clusters natively, with master and replica nodes and automatic failover. Memcached distributes on the client side, using a sharding algorithm you implement yourself. Managed services offer both — and for new deployments, ElastiCache and Memorystore now default to the BSD-licensed Valkey fork — which is generally the sensible route for teams without a dedicated platform engineer.
Increasingly, yes — it's the reason this comparison has a third name in it since 2024. Valkey is the Linux Foundation's BSD-licensed fork of Redis 7.2.4, API-compatible, and now the default on the major managed services. If your only hesitation about Redis is the licence, Valkey removes it without changing how you write against the cache.
Deciding which cache your architecture should be built on? We help engineering teams choose infrastructure they can afford to run and, just as importantly, afford to change later. Talk to our team about where your system is heading.
Web developer at Imaginary Cloud, who is enthusiastic about Node.js and everything related to back-end development.
CEO @ Imaginary Cloud and co-author of the Product Design Process book. I enjoy food, wine, and Krav Maga (not necessarily in this order).
LinkedIn
People who read this post, also found these interesting:
.webp)
