In praise of memcached
In praise of memcached
2nd June 2026<br>from jc's blog
If you happen to find yourself in a sysadmin position, or a position where you<br>just so happen to maintain someone’s<br>infrastructure, chances are that at<br>some point in time the topic “we need a cache” comes up.
You think for a moment and reach out for Redis, because you’re used to it, it’s<br>fully featured, and it works! You remember it being a good, solid cache, and you<br>wonder which new features recent releases have brought, and head to its<br>homepage:
Your agents aren’t failing. Their context is.
Inquiring agents want to know:
How can I use Redis Iris as a real-time context engine for AI apps?1
Right, so probably something with AI2. This is sort of understandable, because<br>Redis is a company that wants to make money.
Anyways, Redis homepage aside, you deploy it, and off you go - your trusty<br>cache. You hand the connection string to the people who asked for it, and off<br>you go.
Few months later
After a while, it turns out that cache.set("key", "value") is a really simple<br>abstraction, and definitely easier than INSERT INTO table VALUES ('key', 'value'). People start treating the REmote DIctionary Server as something<br>that’s always there, something that persists data, something that is a<br>database.
You don’t know this. Your ops colleagues don’t know this. Therefore, your<br>alerting doesn’t know this either, because you assume that people treat the<br>cache as something volatile.
You find out that this has been going on when you happen to do something to<br>Redis. Maybe you upgrade it, maybe you move it to another node, maybe your cat<br>hits the eject button on your RAID0 server’s HDD tray.
The issue isn’t that Redis doesn’t have persistence, the issue is that usually,<br>Redis is brought into a stack as a cache, and it is run with the assumption<br>that people treat it that way.
Usually, by the time you realize this, it is already too late, and Redis is too<br>intertwined in the app to really leave its place. Instead, you have the eternal<br>pleasure of maintaining it and monitoring it like a pet.
Enter memcached
First off - what’s a memcached? Easy, ask its website:
What is Memcached?
Free & open source, high-performance, distributed memory object caching<br>system, generic in nature, but intended for use in speeding up dynamic web<br>applications by alleviating database load.3
Wow, first sentence on the page, even with code examples. And look at those cute<br>little mascots at the top!
Memcached is also a cache, similar to Redis. Chances are that you’re using a<br>framework like Django, which supports pluggable<br>caching and allows you to<br>switch between different caching backends.
But why should you use memcached when it has much less features than Redis?<br>Here are my reasons for why these days, I will always prefer memcached over<br>Redis:
Dealing with memcached downtime is incredibly easy, because client<br>libraries generally ignore connection exceptions. For instance, a simple get<br>will just return the default value (or none) if the server is down.
Clustering memcached is wonderful, because memcached actually has no<br>clustering built-in. To “cluster” it, you configure the client library with<br>multiple URLs4, and the client will select the target instance based on<br>hashing the key. If a client-side call detects an instance as done, it<br>removes the node from the<br>hasher.<br>After a certain time, the client will automatically attempt to reconnect and<br>use the dead node.
memcached “solves” the whole persistence issue, because it does not persist to<br>disk. It is therefore a perfect fit to just being scheduled as a stateless<br>workload wherever you desire it.
None of these things are impossible with Redis, it’s just that memcached’s<br>architecture in general more leans towards these directions, which makes it<br>much, much more straightforward from an operations point of view.
But because of memcached being such a relatively simple application (plus the<br>fact that you can run dozens instances of it with ~64 MB cache size and close to<br>no overhead), if I need a cache these days, I usually reach out to memcached.
That said, a lot of “database too slow” problems actually begin their life as<br>“query too slow” or “missing indices”, so be a kind person and help your<br>developers with optimizing their queries.
Also, if you’re curious about some of the decisions behind memcached, the<br>blog contains interesting posts, with one<br>published just in May: “How Long Does That Response Take… For<br>Real?”.
https://redis.io/, accessed 2026-06-02 ↩︎
That said, https://redis.io is probably not the best entrypoint for<br>engineers, that website seems geared to people making purchasing decisions. ↩︎
https://memcached.org, accessed 2026-06-02 ↩︎
Bonus points for using a service discovery mechanism to automatically<br>generate this...