Redis vs Memcached: When the Simpler Cache Is Still the Right One
The comparison everyone links to is a Stack Overflow question closed as opinion-based fourteen years ago. What has changed since then is not the feature list. It is the licence, the fork, and a demand curve falling 46% a year.
Search for this comparison in Germany as of writing and the first organic result is a Stack Overflow question from 2012. Under the title sits the site's own notice: "Closed. This question is opinion-based. It is not currently accepting answers." It was closed five years ago and locked after that. The most-linked answer to this question is one the community decided could not be answered, and Google still puts it first.
That is not a knock on the thread, which is a good thread. It is a note on how old the framing is. Almost every page ranking for this comparison argues the same axis — Redis has more data structures, Memcached is simpler — and almost all of them were written before the two things that now decide the question.
Those two things are a licence change and a demand curve. So this is about when to use Memcached in 2026 rather than about which engine has the longer feature list, and it starts from the assumption that you have already decided you want a cache. Whether a cache is worth adding at all is a separate question with its own answer, and so is which caching pattern you write it with.
What actually changed since 2024
For roughly fifteen years the two projects sat still. Memcached was BSD-licensed and did one thing; Redis was BSD-licensed and did many. Then, in March 2024, Redis stopped being BSD-licensed. Later releases moved to a dual RSALv2 and SSPL arrangement, and in May 2025 AGPLv3 was added as a third option. None of those is an OSI-approved permissive licence in the sense the old comparisons assumed.
The clearest public statement of what that means comes from AWS, on its own comparison page, which puts it as: "Memcached is fully open source (BSD licensing) while Redis OSS 7.2 is the last fully open source version of Redis." A group of former contributors forked 7.2 into Valkey, which is stewarded by the Linux Foundation under a BSD licence.
| Engine | Licence as of writing | Since | Who steers it |
|---|---|---|---|
| Memcached | BSD (3-clause) | unchanged since 2003 | a small independent maintainer group |
| Redis 7.2 and earlier | BSD (3-clause) | unchanged | frozen; this is the last such release |
| Redis 7.4 and later | RSALv2 / SSPL, with AGPLv3 added in May 2025 | March 2024 | Redis Ltd. |
| Valkey | BSD (3-clause) | forked from Redis 7.2 in 2024 | the Linux Foundation |
For most teams reading this, none of that changes anything: running an AGPLv3 server as a cache behind your own application is not a distribution, and no obligation is triggered. It matters if you ship software to customers who run it themselves, if you resell a hosted service built on it, or if your legal review has a list of licences it will not sign off on. That last category is larger than it sounds, and it is the reason a Memcached decision made in 2026 sometimes has nothing to do with throughput.
Is Memcached still relevant?
Yes, in a narrower band of work than it used to occupy, and the band keeps narrowing. It is worth being specific about how fast, because the answer is easy to measure and nobody seems to print it.
Measured against the German market in August 2026, monthly search volume for memcached fell 46% year over year, from 720 a month to 390. The comparison queries fell further: memcached vs redis is down 55%, redis vs memcached down 50%, php memcached down 57%. Those are English-language queries measured inside the EU, so the absolute numbers are small, and the direction is what matters. Every phrase in this vocabulary is shrinking, and none of the competing pages mentions it.
Search volume measures attention, not deployments, and there is a lot of Memcached quietly running in production that nobody is googling. But the trend is consistent enough across unrelated phrasings that the honest summary is this: the argument is being settled by attrition, not by benchmark. New projects reach for Redis, or now Valkey, and Memcached holds the installations that already exist and the narrow set of workloads described below.
What this is not
This is not a claim that Memcached is dead or unmaintained. It receives releases, it is genuinely faster at one thing, and there are workloads where it is still the better answer. It is a claim that the number of such workloads is smaller every year, which is a different statement and a checkable one.
The one thing Memcached is genuinely better at
Memcached is multithreaded. Redis executes commands on a single thread, with multithreaded I/O available for reading and writing sockets but not for running the commands themselves. Give both engines a machine with sixteen cores and Memcached will use them; Redis will use roughly one for command execution.
That is a real architectural difference and it produces a real result. It is also narrower than it first appears, because the way you scale Redis is not to give one process more cores — it is to run more processes. Shard across four Redis instances and you have four command threads, on hardware that is usually cheaper than the single large machine. On a managed platform this happens without you thinking about it, which is why a Redis vs Memcached performance comparison tends to look more decisive on a benchmark chart than on a bill.
Which is faster, Redis or Memcached?
On raw GET and SET of small values, at high concurrency, on one large machine: Memcached, by a margin usually reported in the tens of percent. Two of the pages currently ranking for this comparison put numbers on it. A production benchmark published on Medium reports roughly 470,000 requests per second for Memcached against 410,000 for Redis on read-heavy tests, with average latency of 1.2 ms versus 1.8 ms. A site built specifically for this query summarises it as a "~20-25% GET/SET edge at high concurrency" for Memcached, and adds that "Redis wins everything else."
Those are other people's measurements, quoted as such, and they should be read with the usual caution about benchmarks you did not run: the hardware, the value sizes, the client library and the pipelining settings all move these numbers more than the engine choice does. What they establish is the shape of the result, not the value. The shape is that Memcached wins the narrow contest and loses the wide one.
The practical question is whether the narrow contest is your contest. If your cache is at 20% CPU on one core, a 25% throughput edge buys you nothing you can spend. If you are saturating a single Redis process at hundreds of thousands of operations per second and you cannot shard, it is the whole argument. Most applications are in the first group and think they are in the second.
What are the limitations of Memcached?
The simplicity is genuine, and the constraints that come with it are the kind you discover in production, not in the documentation. Five are worth knowing before you choose.
| Limit | Default as of writing | What happens when you hit it |
|---|---|---|
| Value size | 1 MB per item, changed with -I | SERVER_ERROR object too large for cache, and the write is rejected, silently in many clients |
| Memory | 64 MB, changed with -m | least-recently-used eviction inside the affected slab class, not across the whole cache |
| Replication | none | losing a node loses that node's share of the cache; the client reshards and the database absorbs the misses |
| Persistence | none | a restart empties the cache completely, every time |
| Authentication | none in the default configuration | anything that can reach the port can read and write every key |
The value-size limit is the one that catches people. A 1 MB ceiling sounds generous until a serialised object crosses it under real data, at which point the store fails and, depending on the client, does so without raising anything you would notice. The failure looks like a cache that suddenly has a terrible hit rate for one class of key.
The memory behaviour is subtler. Memcached allocates memory in slab classes with fixed chunk sizes, and an item goes into the smallest chunk that will hold it, wasting the remainder. Historically, memory assigned to one slab class stayed there, so a workload whose value sizes shift over time could end up with plenty of free memory in the wrong class and evictions in the right one. Later versions added automatic slab rebalancing, but the underlying model is still fixed-size chunks, and it is the reason Memcached memory usage is harder to reason about than the flat number suggests.
port 11211
Memcached listens on port 11211, historically on both TCP and UDP. The UDP listener is the reason the port has a reputation: in 2018 it was used for record-setting amplification attacks, because an unauthenticated UDP service that returns more data than it receives is exactly what a reflection attack needs. Modern builds disable UDP by default as of writing, but the default installed by a distribution package is worth checking rather than assuming.
# Memcached: no auth in the default configuration, so binding matters
memcached -m 64 -I 1m -l 127.0.0.1 -p 11211 -U 0
# | | | | |
# | | | | disable the UDP listener
# | | | default TCP port
# | | bind to loopback only
# | max item size (default 1 MB)
# memory limit in MB (default 64)
# Redis on Runsite: TLS is on by default, the credential is in the URL
REDIS_URL=rediss://default:password@redis.runsite.app:6379Memcached has supported TLS as a build-time option since 2019, but it is a flag you compile in, not a default, and many distribution packages ship without it. If you run Memcached across anything other than a private network, that is a detail to verify rather than assume.
memcache vs memcached: not two products
A large share of the search traffic for this phrase is not asking about the server at all. In PHP, memcache and memcached are two different client extensions: the older memcache, and the newer memcached, which wraps the libmemcached library and supports more of the protocol. Both talk to the same Memcached server. Choosing between them is a client-library decision with nothing in it about Redis.
If you arrived from a hosting control panel
Shared hosting panels like cPanel and LiteSpeed, and the object-cache settings in WordPress, Nextcloud and Moodle, frequently offer Memcached and Redis as two checkboxes with no explanation. In that context the answer is nearly always Redis if the panel offers it, because the CMS object-cache plugins are better maintained against Redis and because the persistence and eviction behaviour is easier to reason about when something goes wrong. None of the architectural argument below applies; you are picking a backend for someone else's plugin.
Redis vs Memcached vs Valkey
The two-way comparison is the one people search for and the three-way one is the one that describes 2026. Valkey is a fork of Redis 7.2 maintained under the Linux Foundation, and AWS states plainly on its own page that "Valkey is fully open source (BSD licensing) and will always be open source as it's stewarded by the Linux Foundation."
For an application developer, the practical position as of writing is that Valkey is protocol-compatible with the Redis version it forked from, so existing clients connect to it without changes, and the commands you use in a cache are the same commands. The divergence is at the edges: newer modules, newer data types, newer clustering behaviour. It widens with every release on both sides. Anything you rely on beyond core commands is worth checking against the specific version rather than against the general claim of compatibility.
Which splits the question in two. First: do you want a rich in-memory data structure server or a plain key-value cache? Then, if you want the first: on Redis Ltd.'s licence or the Linux Foundation's? They are separate decisions, and most of the pages ranking for this comparison still fold them into one.
A cache with no persistence is not a GDPR exemption
It is tempting to treat the ephemeral cache as the component that does not count. It holds no durable copy, it empties on restart, and it is the last thing anyone adds to a processing record. Under the GDPR that reasoning does not hold: the obligation attaches to processing personal data, not to storing it durably, and a cache holding session tokens, user profiles or rendered pages containing someone's name is processing personal data for as long as the key lives.
What changes between the two engines is the shape of the risk, not whether it exists.
- Memcached. No persistence means no on-disk copy to secure, restore or delete, which genuinely removes one class of exposure. It also means no audit trail: after an incident there is nothing to examine, and no default authentication means the access-control story is entirely about the network.
- Redis or Valkey. Persistence is optional, and if you enable RDB or AOF you have created a durable file containing personal data, which needs the same residency answer, the same retention rule and the same deletion path as your database. Access control exists in the engine, which is one fewer thing resting on the firewall.
- Both. The cache needs to sit in the same jurisdiction as the database it caches, under the same processor agreement, named in the same documents. A processing record that lists only the database describes a system you are not running.
None of that is hard to satisfy, and it is skipped constantly because the cache is the component teams forget they are running. It is also the one thing none of the pages currently ranking for this comparison mentions — across three results pages and twenty-six organic results, not one says where the cache physically runs or who the processor for it is. Where your data actually sits, and why that is the question a regulator asks first, applies to a cache exactly as it applies to a database.
When to use Memcached: three questions, not a feature table
Feature tables are how this comparison is usually presented and they are close to useless for deciding, because they list capabilities when what you have is requirements. Three questions get you there faster.
- Do you need anything other than string keys and string values? Counters, queues, rate limiters, leaderboards, sets, sorted sets, streams, pub/sub. If yes, the decision is already made — Memcached does not have them, and reimplementing a rate limiter on top of a plain key-value store is a project, not a configuration.
- Does anything need to survive a restart? The question is not whether losing the cache is acceptable, which is true by definition of a cache. It is whether losing it on every deploy is. A cold cache after each release means every deploy sends full traffic at your database. Memcached empties on every restart, with no option.
- Are you actually CPU-bound on one cache process? Not theoretically, measured. If a single Redis process is saturated at high concurrency and sharding is genuinely unavailable to you, Memcached's multithreading is a real answer. If you have not measured this, you are not in this case.
If all three come out in Memcached's favour, meaning plain strings, throwaway data and a measured single-process ceiling, then it is the better tool, and it is a pleasure to operate precisely because there is so little of it. That combination is uncommon, and it gets less common every year. Everything else is Redis or Valkey, and the choice between those two is a licensing question rather than a technical one.
How Runsite handles it
Worth saying plainly: Runsite runs managed Redis hosting in the EU and does not offer Memcached. If your answers to the three questions above point at Memcached, this platform is not the one that serves that case, and the rest of this section will not be useful to you.
For everyone else, it is Redis 7+ as a toggle beside your application instead of a separate account with a separate vendor, with TLS on by default as of writing, so the string you are handed is rediss:// rather than something you switch on afterwards. What matters against the comparison above is mostly what the plan gives you.
- Persistence is a plan choice, not an afterthought. The free 50 MB instance is in-memory only and runs for 30 days before it needs an upgrade; RDB snapshots start on the €5 Starter plan, and RDB with AOF on Standard at €13. The engine difference in question two above is only worth paying for if you actually enable it.
- Sharding, not cores. Scaling a cache means running more instances, not giving one instance more cores, so the multithreading argument mostly resolves into a sizing decision instead of an engine decision.
- Location. Instances run in the Frankfurt, Germany region. Keys, sessions and any RDB or AOF files stay inside the EU, and the signed data processing agreement attached to every plan, the free one included, covers the cache and the database it sits in front of as one arrangement, not two.
The free instance is enough to run real traffic against a real hit rate and find out whether the second copy of your data earns its place, before anyone pays for it.
The short version
- The top-ranked page for this comparison is a Stack Overflow question closed as opinion-based in 2021 and originally asked in 2012. Most of the pages under it argue a feature axis that stopped being the deciding one in 2024.
- What changed is the licence. Redis 7.2 is the last BSD release; later versions are RSALv2/SSPL with AGPLv3 added in May 2025. Valkey forked 7.2 and is BSD under the Linux Foundation.
- Memcached is genuinely faster at raw GET and SET at high concurrency, by roughly 20-25% in other people's published benchmarks, because it is multithreaded and Redis executes commands on one thread.
- That advantage mostly disappears when you shard, because more Redis processes means more command threads, usually on cheaper hardware than one large machine.
- Memcached's limits are 1 MB per value by default (
SERVER_ERROR object too large for cache), 64 MB of memory by default, no replication, no persistence, and no authentication in the default configuration. - Slab allocation means memory usage is harder to reason about than the flat number suggests: memory can be free in one slab class while another is evicting.
- Port 11211 carried UDP by default for years and was the vehicle for the 2018 amplification attacks. Modern builds disable UDP, but check instead of assuming.
- In PHP,
memcacheandmemcachedare two client extensions for the same server, not two products. If you arrived from a hosting control panel, that is the question you were asking. - Three questions decide it: do you need anything beyond string keys and values, does anything need to survive a restart, and are you measurably CPU-bound on one cache process. All three have to favour Memcached for it to win.
- Neither engine exempts you from data residency. A cache holding session tokens is processing personal data, and it needs the same jurisdiction and the same processor agreement as the database it sits in front of.