In Praise of Memcached: Why Simpler Caching Might Be Better

A blog post praising memcached hit the Hacker News front page with 242 points and 100 comments, reigniting the eternal Redis vs memcached debate. The core argument: Redis's flexibility is a trap that leads to operational pain.

The post generated some predictable "this is AI-written" accusations (it was not) but also surfaced a genuinely interesting architectural discussion about what caches should and should not do.

Last updated: June 23, 2026

The Core Argument

The author's thesis is simple: Redis gets deployed as a "cache" but inevitably becomes treated as a persistent database by developers who do not understand its volatility assumptions. When Redis goes down (upgrades, hardware failures), the impact is severe because it is now storing critical data.

Memcached, by contrast, is architecturally constrained in ways that prevent this drift:

1. Graceful degradation is built in. Client libraries ignore connection exceptions. A simple get returns the default value (or none) if the server is down. Your application does not crash - it just runs slower while the cache refills.

2. No built-in clustering forces client-side distribution. Memcached has no cluster mode. Clients handle distribution through key hashing. When nodes fail, clients automatically remove them from rotation and later attempt reconnection. This sounds like a limitation, but it means no cluster state to manage, no consensus protocols to debug at 3am.

3. No persistence means true statelessness. Memcached does not persist to disk. You can deploy it as a stateless workload without worrying about data loss because there is no data to lose. It is genuinely ephemeral.

That constraint is the whole architectural point. A cache should be easy to delete. If deleting it requires a migration plan, an incident bridge, and a data-recovery checklist, you probably built a database-shaped system and named it cache.

For AI infrastructure teams, the same distinction shows up in agent spend guardrails and agent-native backends: the operational contract matters more than the label on the component.

What HN Is Saying

The discussion produced some excellent technical depth.

The Redis defenders pushed back on the framing:

"Redis is brought into a stack because (most importantly!) it's fast and (almost as importantly!) because it's simple. I have very very rarely experienced Redis being treated as a persistent store."

One commenter with 15 years of Redis experience noted they had "never had to manage clustering or had any issues with it" even for games with 30- or 60-tick state updates across multiple regions.

The operations perspective was more sympathetic to the original post:

"I've had teammates that treated Redis as an actual durable production database and operated that way. It's not unreasonable for a new dev to assume this unless told otherwise."

Another commenter laid out the practical rules for using Redis safely as a cache:

1. Wrap your client library so it is impossible to store anything without an expiry date
2. Either turn off persistence, or use a separate database for the cache
3. Set up a reasonable maxmemory value with an appropriate eviction policy
4. Resist the urge to use complex data structures - if you try to update a single field on an expired hash, you will end up with an incomplete object

The performance discussion was illuminating. A commenter from Notion reported:

"memcached is about a bazillion times faster than redis at doing the simple KV cache job. it's got threads. at notion we use redis for a lot of things, but actual caching we leave to memcached"

The numbers from another commenter comparing local cache (APCu), memcached, and MariaDB:

APCu       avg=0.000318ms
Memcached  avg=0.039714ms
MariaDB    avg=0.019541ms

The interesting observation: MariaDB was actually faster than memcached in this test because the network hop dominates. "Don't even start a socket if possible."

The architecture purists argued for separation of concerns:

"Redis is a great piece of tech but it suffers from trying to be good at two different jobs (persistent data structures, volatile cache) which should not be combined. Indeed in Redis itself they don't combine well - persistence is globally on or off."

The pragmatists countered that most teams will end up needing Redis anyway:

"I'd almost guarantee a large enough team using memcache will find a way to need Redis. And then we're maintaining 2 cache technologies."

The Real Question: When Do You Need Either?

Several commenters asked the practical question: when do you actually need to move from database-level caching to a dedicated cache layer?

One commenter summarized it well:

"The most common first thing to cache is getting the current user, because this ends up being a very hot path for most stateless systems. Because you need to get the current user for almost every request, it's quite easy for getting the current user to be 50% of database load."

Another offered a decision framework:

• Do you need to recover from a reboot with queues intact? You need persistence
• Is it a distributed system? You need coordination
• Do you have complex multi-step workflows? You might need data structures
• If you answered no to all of these: import Queue from queue might be enough

The performance hierarchy from another commenter:

Servers are so insanely large (up to 400 Cores) now that you can
get meaningful scale on a single box. If you can colocate the app
and cache on the same server, you can get many orders of magnitude
better performance, regardless of which cache it is.

The boring decision rule:

This is why caching decisions belong in architecture review, not only performance tuning. The wrong cache can quietly become the data model.

The Slab Allocation Footgun

Several commenters noted that memcached is not actually as simple as it appears:

"The memcache slab pools are a leaky abstraction that you may end up having to manage operationally, and it's another way Redis is simpler."

Memcached pre-allocates memory in fixed-size "slabs" for items of different sizes. If you store a lot of 50-byte items and then start storing 500-byte items, you can run into slab starvation where the cache evicts data even though there is technically free memory. Most developers "just reach for redis at that point."

Non-Caching Uses of Redis

The thread surfaced several common patterns where Redis's extra features matter:

• Rate limiting via leaky bucket algorithm
• Feature flags and stats tracking
• Websocket pub/sub
• Background job queues (Sidekiq, Celery)
• Distributed task coordination
• Atomic operations across threads (INCRBY)
• Lua scripts for complex atomic operations

For these use cases, memcached is not a viable alternative - you need the data structures. The argument is really about whether you should use the same Redis instance for caching and for these stateful operations.

That separation also matters for AI apps. A retrieval cache, prompt-cache ledger, job queue, and user-facing database should not silently collapse into one Redis deployment because it was convenient during prototyping. If you are building with serverless databases, queues, and vector stores, compare the same boundary discipline in Convex vs Supabase for AI apps and prompt caching for Claude API production.

The Verdict

The discussion converged on a nuanced position:

For pure caching: Memcached's constraints are features. The lack of persistence, the dumb client-side clustering, the graceful degradation - these all push you toward correct cache usage patterns.

For stateful operations: Redis (or Valkey, now that licensing is weird) is the right tool. But configure it as a persistent store with appropriate backup strategies, not as a "cache that happens to persist."

For most teams: Pick one and be disciplined. The real problem is not the technology - it is developers who do not understand the difference between a cache and a database. Memcached makes it harder to confuse the two. Redis makes it easier to do powerful things and also easier to shoot yourself in the foot.

As one commenter put it: "if you're letting a junior dev who refuses to read product documentation the responsibility of architecting production systems, then your problem isn't Redis."

For model-serving infrastructure, do not confuse this with transformer KV cache. That is a different cache with a different failure mode. The KV caching transformer inference guide covers that layer.

FAQ

Is memcached better than Redis for caching?

Memcached can be better for pure ephemeral caching because it is intentionally simple, stateless, and easy to discard. Redis is better when you need richer data structures, atomic operations, pub/sub, queues, or coordination.

When should I choose Redis instead of memcached?

Choose Redis when the workload needs stateful operations: counters, rate limits, locks, pub/sub, background jobs, sorted sets, hashes, streams, or Lua-backed atomic workflows. Use it deliberately as stateful infrastructure, not as a vague cache.

Is Redis safe as a cache?

Yes, if you configure it like a cache: strict TTLs, maxmemory, eviction policy, separate instances for cache and durable-ish state, and operational playbooks for cold starts. Problems start when teams treat Redis as a durable database without designing for that.

What is the biggest memcached downside?

Memcached is simple, but not magic. Slab allocation, item sizing, network latency, and client-side distribution still require operational understanding. Its constraints help prevent database drift, but they do not remove capacity planning.

Should AI apps use Redis or memcached?

Use the same rule as any backend. For throwaway response, retrieval, or computed-value caches, memcached is often enough. For queues, rate limits, coordination, or structured state, Redis or Valkey may fit. Durable user data belongs in a real database.

Sources

• In Praise of Memcached - Original Post
• Hacker News Discussion
• Memcached Internals: Slab Allocation (referenced in thread)
• Memcached documentation
• Redis data types documentation
• Redis eviction policy documentation