# Redis vs Memcached: Which Cache to Choose in 2026 > Memcached is faster at one thing and simpler at everything. What changed in 2026: Redis went AGPLv3, Valkey took the BSD licence, and demand fell 46%. 1. [Home](/) 2. [Blog](/blog) 3. Redis vs Memcached: When the Simpler Cache Is Still the Right One CachingAugust 27, 202612 min read # 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. ## The short version The comparison everyone links to is a Stack Overflow question closed fourteen years ago. What changed since is the licence, the Valkey fork, and demand falling sharply year on year. Memcached is still the better fit for plain string keys, genuinely disposable data, and a workload heavy enough to saturate one large multi-core machine. [Teo Marquardt](/about#author) 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](/blog/when-to-use-redis-cache) is a separate question with its own answer, and so is [which caching pattern you write it with](/blog/cache-aside-write-through-write-behind). ## 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 | The licence column is the part of this comparison that moved. The feature columns did not. 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. bash ``` # 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:6379 ``` Memcached 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. The two also differ in what happens when memory runs out, which is a decision Memcached makes for you and Redis hands to you: [the eviction policy and the OOM error it produces](/blog/redis-oom-command-not-allowed) is the Redis-side version of this. * **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](/blog/gdpr-data-residency), 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. 1. **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. 2. **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. 3. **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](/services/redis) 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 comes with every plan.** As of writing, every Redis plan from the €5 Starter up includes RDB snapshots and an append-only file, and the old free in-memory-only instance is no longer offered. The engine difference in question two above only counts in Redis's favour if you actually rely on data surviving a restart. * **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 German region. Keys, sessions and any RDB or AOF files stay inside the EU, and the signed data processing agreement attached to every plan covers the cache and [the database it sits in front of](/services/postgresql) as one arrangement, not two. A Starter instance on the €5 of credit every new account starts with is enough to run real traffic against a real hit rate and find out whether the second copy of your data earns its place. ## 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, `memcache` and `memcached` are 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. Related service ## Managed Redis on Runsite Deploy from a single git push and keep active apps warm — no cold starts, hosted entirely in the EU with a signed GDPR DPA on every plan. [Explore Managed Redis](/services/redis) [Back to all articles](/blog) FAQ ## Frequently Asked Questions Common questions about this service. ### Is Memcached still relevant? Yes, but in a narrowing band of work. It remains a good fit for a specific profile: plain string keys and values, data that is genuinely disposable on restart, and a workload heavy enough to saturate a single-threaded process on one large multi-core machine. Outside that profile the reasons to choose it have been eroding for years, and the search data reflects it — measured against the German market in August 2026, monthly volume for \`memcached\` was down 46% year over year, with the comparison queries down 50-55%. That is a proxy for attention rather than for installations, and there is a great deal of Memcached running quietly in production that nobody is searching for. The fair summary is that it is a maintained, capable, extremely simple cache that new projects rarely start with, and that the argument against it is not that it is worse at what it does but that what it does covers less ground than it used to. ### What are the limitations of Memcached? Five, and all of them follow from the same design decision to keep the server as simple as possible. Values are capped at 1 MB by default, changed with the \`-I\` flag; exceed it and the write is rejected with \`SERVER\_ERROR object too large for cache\`, which many clients swallow without raising anything visible. Memory defaults to 64 MB and is allocated in slab classes with fixed chunk sizes, so memory can sit free in one class while another is evicting, which makes usage harder to reason about than a single number suggests. There is no replication: losing a node loses that node's share of the cache, the client reshards, and your database absorbs the misses. There is no persistence at all, so every restart, including every deploy, starts from an empty cache. And there is no authentication in the default configuration, meaning anything that can reach port 11211 can read and write every key. SASL exists, but it has to be enabled deliberately. None of these is a defect; each is the cost of a server with very little in it. ### When should you not use Redis? Three situations, and only the first is common. If your legal or procurement process will not accept RSALv2, SSPL or AGPLv3, which applies mainly to teams that ship software customers run themselves or resell a hosted service built on it, then Redis 7.4 and later is off the table, and the answer is Valkey or Memcached rather than a workaround. If you have measured a single Redis process saturated at high concurrency and sharding is genuinely unavailable to you, Memcached's multithreading is a real answer to a real problem. And if you are reaching for Redis as a primary database rather than as a cache, the question changes entirely: durability guarantees, backup and restore, and query patterns become the criteria, and a relational database usually wins on all three. Notably, none of these is about speed. Redis is fast enough for effectively every application that is considering this comparison. ### Is Valkey compatible with Redis? At the level most applications care about, yes. Valkey forked from Redis 7.2, so it speaks the same wire protocol and the same core commands, and existing Redis clients connect to it without code changes — the connection string, the GET and SET calls, the TTL handling and the data structures all behave as they did. The caveat is that compatibility is a snapshot rather than a promise. Both projects have shipped releases since the fork and both continue to add features independently, so the further you get from core commands, the less the general claim tells you and the more you need to check a specific version. Modules, newer data types and clustering behaviour are where divergence shows up first. As of writing, a straightforward application cache moves between the two without changes; anything depending on version-specific behaviour should be tested against the exact build you intend to run. Keep reading ## Related articles [Caching12 min readWhen to Use Redis as a Cache (and When It Makes Things Worse)A cache is a second copy of your data that is allowed to be wrong. This is the decision frame: what to cache, what never to, the four failures that only appear in production, and why a cache full of sessions is a compliance object.Aug 21, 2026Read](/blog/when-to-use-redis-cache)[Caching13 min readCache-Aside, Write-Through, Write-Behind: Choosing a Caching PatternSix names for what is really two decisions. The axes people conflate, the race that makes cache-aside delete instead of update, and why every canonical write-behind implementation is deprecated.Aug 24, 2026Read](/blog/cache-aside-write-through-write-behind)[Compliance9 min readWhere to Store EU User Data: What GDPR Actually RequiresA customer's security review asks where their data physically lives and whether it leaves the EU. GDPR has no hard rule that personal data must stay in Europe — but every transfer out needs a legal mechanism, and EU residency is the simplest way to skip that problem entirely.Jul 10, 2026Read](/blog/gdpr-data-residency) ## Your app deserves to be online €5 of credit on signup. Deploy in under a minute. No credit card needed. [Start deploying](https://dashboard.runsite.app/login)[View documentation](https://docs.runsite.app) --- Source: https://runsite.app/blog/redis-vs-memcached