Redis vs Memcached in 2026: Features, Memory and Speed Tested

Redis vs Memcached is the oldest question in caching, and most answers to it are a decade old. Both keep data in memory and answer in well under a millisecond; Memcached does one thing, caching strings, while Redis adds data types, persistence and replication on top. This guide is for developers choosing a cache for a web app in 2026. It compares the two on what actually differs today, and reports what we measured when we ran the current release of each on the same small server: memory used for the same data, and requests per second.

On this page

• Quick verdict for a new app
• Feature by feature
• We tested both on the same machine
• Threads: the argument that used to decide it
• What Memcached still does better
• What only Redis can do
• Which one to use
• Moving from Memcached to Redis
• FAQ

Quick verdict for a new app

For a new web app, use Redis (or Valkey). On a small server it is at least as fast as Memcached in our test, uses about the same memory for plain cached strings, and also gives you sessions that survive a restart, counters, queues and pub/sub from the same service. Choose Memcached only when you need a pure string cache on a large many-core machine, or your stack already depends on it.

Feature by feature

The pattern is clear: every feature Memcached has, Redis has too. The reverse is not true.

We tested both on the same machine

Most comparisons quote benchmarks from years ago, or none at all. We ran Redis 8.10.3 and Memcached 1.6.39, both built from source, side by side.

Setup. A Linux virtual machine (WSL2) on a 4-vCPU laptop. Each server got 2 CPU cores; Memcached ran 2 worker threads, Redis its default single command thread with persistence off. The same client, a small raw-socket program we wrote that speaks both protocols, ran on the other 2 cores with 50 connections against 100,000 keys holding 100-byte values. Five runs of 5 seconds each; we report the median. Measured 7 November 2026.

Memory for the same data

For plain cached strings the two are effectively the same. Memcached starts smaller, and grew by a few megabytes more while loading, because it hands out memory in fixed-size slabs.

Requests per second (2 server cores, 50 connections)

What we found.

1. Without pipelining, Redis was faster here, by about 60%, and the run ranges did not overlap. Read that with care: the client is our own program, it parses two different protocols, and we did not measure how much of the gap its parsing accounts for. Our guess is that on 2 cores, Memcached’s threads compete with each other for the same cores, but we did not prove it.
2. With pipelining, they tied. The ranges overlap, and at around 600,000 to 700,000 requests a second our single-threaded client is probably part of the limit for both.
3. Pipelining mattered far more than the choice of cache: about 8 to 14 times the throughput on both.

This is a small-machine test on purpose, because that is what most apps rent. It is not the whole story: Memcached’s design pays off when a server has many cores and thousands of clients, which this test does not cover. Treat the numbers as “what to expect on a small instance”, not a universal ranking.

Threads: the argument that used to decide it

The classic advice was “Memcached is multi-threaded, Redis is single-threaded, so Memcached scales better.” That was true and still partly is: Memcached spreads requests across all its threads, while Redis runs every command on one main thread.

Two things have changed. Since version 6, Redis can move network reading and writing onto extra I/O threads, which is designed to narrow the gap on bigger machines (we did not test that). And most apps never come close to the limit of one Redis thread, which handled about 80,000 requests a second in our test without any batching. If you reach that, pipelining or a second instance is usually cheaper than switching.

What Memcached still does better

• Many cores, one big cache. On a large machine serving huge numbers of small GETs, Memcached uses every core without any tuning.
• Simplicity. There is almost nothing to configure and nothing to persist. For a throwaway cache, that is a feature.
• Predictable memory. The slab allocator avoids fragmentation surprises on long-running caches, at the cost of some wasted space per size class.
• Existing stacks. Older PHP setups and some frameworks have long-standing Memcached support, and WordPress can use it through common object-cache plugins (as it can Redis).

What only Redis can do

These are the reasons most new apps pick Redis even when they only “need a cache” today:

• Sessions that survive a restart. With persistence on, users stay logged in after the cache restarts. Memcached logs everyone out.
• Richer counters and rate limits. Both have atomic increments, but Redis can combine a counter, its expiry and a check atomically in one Lua script or MULTI transaction.
• Job queues and events. Lists, Streams and Pub/Sub power libraries such as Sidekiq, Celery and BullMQ. See our Redis job queue guide and Redis Streams tested.
• Rich structures. Leaderboards with sorted sets, objects with hashes, unique visitors with HyperLogLog.
• A choice of what happens when memory is full. Refuse writes to protect important data, or evict for a cache.

Which one to use

• A new web app, any language: Redis or Valkey. One service covers cache, sessions and queues.
• A pure cache on a large many-core server, already tuned for Memcached: keep Memcached.
• WordPress object cache on shared hosting: use whichever your host provides; both work.
• Sessions or anything you would mind losing on restart: Redis with persistence. Memcached cannot do it.
• You care about an open source licence: Memcached is BSD; so is Valkey, the Redis fork. Our Valkey vs Redis comparison covers that choice.

Distance matters more than either engine. A cache in another country adds its round trip to every read; put it in the same region as the app.

Moving from Memcached to Redis

1. Swap the client, not the logic. get, set with an expiry and delete map directly to Redis GET, SET key value EX seconds and DEL.
2. Do not copy the data. A cache rebuilds itself. Point the app at Redis and let it warm up.
3. Pick an eviction policy. For a pure cache, set allkeys-lru so Redis behaves like Memcached when full (eviction policies explains each one). If you will also store sessions or queues there, keep “refuse writes” instead, or run two separate stores.
4. Watch memory for a day and size the instance for your working set.

On Voroa, a key value store asks this as When memory is full: keep Keep everything for sessions and queues, or choose a drop option for a pure cache. It runs in Mumbai next to the web services you deploy, and the connection URL goes in an environment variable. Details are in the Key Value guide.

Put your cache next to your app

A Redis-compatible store in Mumbai, billed in rupees with a GST invoice, with a free size to start. See the sizes on the managed Redis page.

FAQ

Is Redis faster than Memcached? On our 2-core test, Redis was faster without pipelining and tied with it. Memcached can pull ahead on large many-core servers with many clients, which we did not test.

Does Memcached use less memory than Redis? For plain strings, about the same: 16.7 MB in Redis and 16.8 MB in Memcached for our 100,000 keys. Memcached’s empty process is smaller.

Can Memcached save data to disk? No. A restart empties it. Redis can write snapshots and an append-only log.

Is Memcached still used in 2026? Yes, especially in older PHP stacks and at very large scale. Most new projects choose Redis or Valkey for the extra features.

Can I use Redis just as a cache? Yes. Set a memory limit, an eviction policy such as allkeys-lru, and an expiry on your keys, and it behaves like Memcached.

What is the maximum value size? Redis strings can be up to 512 MB. Memcached items are limited to 1 MB by default.

Tested 7 November 2026 with Redis 8.10.3 and Memcached 1.6.39 in WSL2 on a laptop. Found something out of date? Write to support@getvoroa.com.