Redis vs Memcached for Full-Page Caching
Full-page caching is the original 2003-era Memcached use case. It is also the one workload in 2026 where Memcached genuinely earns its keep. Multi-threaded servers, lower per-item overhead, no persistence overhead, and a smaller operational footprint.
The original Memcached workload
Brad Fitzpatrick wrote Memcached in 2003 at LiveJournal because the database was struggling under the load of rendering the same journal pages over and over for anonymous readers. The solution was a simple in-memory key-value store that could cache the rendered HTML for a few minutes and absorb the read traffic. That workload (cache a generated page, return it on subsequent requests until it expires) is the canonical Memcached use case and the one it was literally designed for.
Twenty-three years later that workload still has the same shape and Memcached still has the same advantages on it. The data is ephemeral (you can always regenerate the page from the database). The data is large-ish (50-300KB per page is typical, well within the per-item limit). The traffic pattern is read-dominated (one set per cache rebuild, hundreds or thousands of gets between rebuilds). Persistence is a non-feature: if Memcached restarts, you lose the cache and the application repopulates it within minutes from real traffic.
The Memcached advantages on this workload trace back to design choices that were correct for 2003 and are still correct for the workload in 2026. Multi-threaded I/O means a busy Memcached node can saturate a 10Gbps NIC across all cores; Redis would single-thread the same workload (Redis 6's I/O threading helps for parsing but command execution is still single-threaded). The slab allocator avoids fragmentation but is a constraint elsewhere. The text protocol is simple enough to debug with netcat.
The numbers, with provenance
The benchmark most commonly cited for the Memcached edge is the DevGenius March 2026 comparison on AWS c6i.2xlarge (8 vCPU, 16GB RAM). On simple GET/SET at 256 client connections with 1KB values, Memcached sustained roughly 1.0 million GETs per second; Redis 8.0 sustained 800k GETs per second on the same hardware. The ratio matches earlier 2024 and 2022 benchmarks within noise. It is a real, stable, measurable difference at the synthetic-workload extreme.
The same DevGenius run showed Redis catching up on batched pipelines (10 GETs per round trip): Redis 800k ops/sec, Memcached 750k ops/sec, a 7% Redis edge. Pipelining matters enormously in real applications because the round-trip cost dominates: a worker that fetches 50 fragments per page render gets 50x the throughput by batching them into one pipeline. If your client library and access pattern lend themselves to batching, the Memcached single-call advantage disappears.
Memory efficiency is a third dimension. Memcached's slab allocator is more efficient per item for uniformly-sized data (a 100KB cached page slot is exactly 100KB plus a few bytes of header). Redis encodes small values more efficiently (the ziplist and intset encodings save memory for tiny structures) but at full-page sizes Redis loses that edge. For a 10GB page cache, Memcached and Redis cost approximately the same in RAM with Memcached marginally lower.
The operational case for and against
Memcached's operational story is intentionally barren. There is no persistence to configure, no replication to manage, no Sentinel quorum to maintain, no Cluster to shard. You run memcached with a memory size and a thread count, and that is the configuration. For a pure cache, this minimalism is a feature: less to break, less to monitor, less to learn. Facebook's Scaling Memcache paper (NSDI 2013) describes their use of Memcached at scale and the operational simplicity is part of why they kept it.
The case against is what happens when the workload grows beyond page caching. The moment you want session storage, you need persistence. The moment you want a queue, you need lists. The moment you want pub/sub for cache invalidation, you need pub/sub. Every one of those is a reason to add Redis alongside, and once you have a Redis instance you start asking why you are running both. Many teams have ended up consolidating onto Redis or Valkey for exactly this reason, accepting the slightly lower peak throughput in exchange for one fewer system to operate.
The 2026 answer is: if your workload is pure page caching and likely to stay that way, Memcached is genuinely the right call. If you suspect you will want anything more in the next year (background jobs, sessions, leaderboards, real-time features), pick Redis or Valkey from day one and accept the 5-10% real-workload throughput difference. The migration cost when you do need those features later is more than the throughput cost now.
Where Varnish and CDN fit
Full-page caching in 2026 usually does not actually happen in Memcached or Redis. It happens in Varnish, nginx microcache, or a CDN edge cache (Cloudflare, Fastly, AWS CloudFront, Vercel Edge Network). These layers sit in front of the application and cache the raw HTTP response with no application code running. A cache hit at the CDN returns in 5-20ms with no origin involvement; a cache hit in Memcached requires the origin server to be up, to render the cache key, and to return the response.
That said, the backing-cache layer in Memcached or Redis still matters for everything the CDN cannot cache: per-user pages, authenticated content, partials within a larger page (fragment caching), API responses too short-lived for CDN edge TTLs, and cold-cache rebuilds. The pattern most large content sites use is: CDN for anonymous pages with 60s TTL, Redis or Memcached for fragment caches and computed values, with explicit purge on data change events going through both layers.
For the API response use case specifically, see the companion guide at /use-cases/api-response-caching/. API responses tend to be smaller, more user-specific, and benefit from Redis features (hash-based partial invalidation, pub/sub for invalidation broadcasts) that full-page HTML caching does not need.
FAQ
Is Memcached faster than Redis for page caching?
For pure GET/SET at high concurrency, Memcached has a ~20-25% throughput edge (DevGenius March 2026, AWS c6i.2xlarge). The edge comes from multi-threaded I/O (Memcached uses one thread per connection by default, Redis serves on a single thread plus an I/O thread pool since Redis 6). For full-page caching specifically, that edge is real and measurable.
Should I use Varnish or a backing cache?
Both. Varnish (or nginx microcache, or a CDN like Cloudflare / Fastly) sits in front of your application and caches HTTP responses with no application logic. Behind it, a backing cache (Redis or Memcached) stores fragment caches and computed values your application produces. They are layers, not alternatives.
Does the Memcached edge survive in real workloads?
It narrows. The 20-25% edge is for synthetic GET/SET at peak concurrency. Real workloads include serialization cost, network round-trip dominance, mixed hot and cold keys, and the application logic around each cache call. The edge often shrinks to 5-10% end-to-end. Still real, often not load-bearing.
What size pages should I cache?
Memcached's default 1MB item limit is the practical ceiling for whole pages. Most HTML pages are 50-300KB, well under the limit. For pages over 1MB, fragment-cache instead (cache the expensive partials, render the surrounding HTML on each request). Redis has no comparable per-item limit by default but the cost-per-byte is similar.
How do I invalidate cached pages?
Two patterns. One: time-based expiry (set TTL of 60s-15min, accept eventual consistency). Two: explicit invalidation (DELETE cache key when underlying data changes, often via a model callback or change-data-capture pipeline). Most teams combine both: short TTL plus explicit invalidation on the high-frequency change paths.