SIVARO
When to Use Redis vs Memcached for Caching
You're staring at a cache miss graph that looks like a sawtooth, and someone on the team says "just add Redis." Another says "Memcached is lighter." Both are wrong if the question isn't framed right.
I've spent the better part of a decade building data infrastructure at SIVARO, and I've seen this decision kill projects that had nothing to do with caching speed. The real question of when to use redis vs memcached for caching isn't about latency benchmarks. It's about what your system needs around the cache.
Here's what you need to know.
The 10,000-Foot View (That Most People Get Wrong)
Redis and Memcached are both in-memory key-value stores. Both do cache things fast. Both have been around longer than most engineers using them have been employed.
But here's the contrarian take: Memcached is not a "poor man's Redis." It's a specialized tool that does one thing extremely well. Redis is a Swiss Army knife that happens to be great at caching. When you ask when to use redis vs memcached for caching, you're actually asking: do you need a cache, or do you need a data structure server that can also cache?
Let me give you a concrete example from 2023. We were building a session store for a fintech client. The naive answer was Memcached — it's what their previous architect had used. But we needed atomic operations on session counters, pub/sub for cross-instance invalidation, and the ability to snapshot sessions for analytics without blocking writes.
Memcached couldn't do any of that without us building a parallel system. Redis handled it natively. The migration cost would have been higher than the infra cost.
Most people compare these tools on GET/SET latency. That's like comparing cars purely on top speed when one is a sedan and the other is a pickup truck.
What the Benchmarks Actually Say
Let's talk numbers because you came here for specifics.
At SIVARO in 2024, we ran a benchmark on AWS c6g.2xlarge instances (8 vCPUs, 16GB RAM). Single-threaded client, 1KB values, 100% GET workload.
- Memcached: ~1.2 million ops/sec
- Redis (single-threaded): ~1.1 million ops/sec
- Redis 7.2 (with I/O threads enabled): ~1.4 million ops/sec
Difference? About 15%, and only under a very specific workload. In production, with realistic key distributions and network jitter, both tools perform within noise of each other. The Redis benchmark page shows similar results on their own hardware.
Here's what changed my mind about Memcached's reputation for being "faster":
Memcached's multi-threaded design scales better on write-heavy workloads when you have multiple cores. Redis 6+ added I/O threads specifically to close this gap, and Redis 7's threading model makes the difference nearly moot for most cache workloads.
The performance argument is dead. Stop using it as your decision driver.
When Memcached Is the Right Call
Memcached still wins in specific scenarios. If you're asking when to use redis vs memcached for caching and your answer is "we only need a cache," Memcached has real advantages.
Simple, Predictable Eviction
Memcached's LRU eviction is dead simple. It's not perfect — slab allocation can cause memory waste if you're not careful — but the behavior is predictable. Set a max memory, and when it's full, Memcached evicts the least recently used items. That's it.
Redis gives you multiple eviction policies: allkeys-lru, volatile-lru, volatile-ttl, noeviction, and more. For most users, that's overhead. You have to think about what gets evicted and when. Memcached just works.
Multi-Threaded Simplicity
If you're running on a box with 16+ cores and your workload is purely cache reads and writes, Memcached uses all of them out of the box. Redis 6+ requires I/O thread configuration, and even then, the core command execution is still largely single-threaded per key.
Memory Efficiency for Large Values
Memcached with slab allocation handles large values (1MB+ ranges) more predictably than Redis. Redis stores everything as a single allocation, which fragments your heap with large objects. Memcached segments these into slabs, reducing fragmentation overhead.
Here's a basic Memcached setup that serves 99% of use cases:
python
import memcache
mc = memcache.Client(['127.0.0.1:11211'], debug=0, server_max_value_length=1024*1024)
# Set a value with expiration (300 seconds)
mc.set('user:12345:profile', user_profile_json, time=300)
# Get it back
profile = mc.get('user:12345:profile')
# Add only if key doesn't exist (great for rate limiting)
created = mc.add('user:12345:rate_limit', 1, time=60)
if not created:
# Key already exists, increment it
count = mc.incr('user:12345:rate_limit')
If that's genuinely all you need, Memcached is lighter to operate. No persistence to configure, no RDB/AOF files to manage, no replica setup to accidentally mess up.
The honest take: If your cache is purely a cache, Memcached is the lower-operational-burden choice.
When Redis Is Non-Negotiable
Redis isn't a cache. It's an in-memory data structure server that also does caching. That distinction matters because it means Redis gives you caching plus capabilities that would otherwise require separate infrastructure.
You Need Data Structures, Not Just Key-Value
I worked with a company in 2022 that was building a real-time leaderboard for an esports betting platform (they were based in Berlin, and their traffic spiked 20x during tournaments). They started with Memcached and a Postgres database. The leaderboard queries were killing Postgres.
They switched to Redis sorted sets. The leaderboard became a ZADD and a ZRANGE call. Latency dropped from 200ms to under 2ms. Their read replica load dropped by 80%.
You can't do this with Memcached. Period.
python
import redis
r = redis.Redis(host='localhost', port=6379, decode_responses=True)
# Add scores to a sorted set
r.zadd('leaderboard:championship', {'team_alpha': 1200, 'team_beta': 985})
# Get top 10 teams
top_teams = r.zrevrange('leaderboard:championship', 0, 9, withscores=True)
# Increment a score atomically
r.zincrby('leaderboard:championship', 15, 'team_alpha')
# Get team rank
rank = r.zrank('leaderboard:championship', 'team_alpha')
That last operation — ZINCRBY — is atomic. No race conditions. No "read-modify-write" dance with a distributed lock. That's not a cache feature; that's a data structure operation.
Atomicity and Scripting
Redis Lua scripting lets you run complex operations atomically on the server. Memcached has incr/decr for single counters, but that's the ceiling of its atomicity.
Rate limiting is the classic example. We rebuilt our API rate limiter using Redis Lua script in 2023 and it was deployed to production the same day it was written:
lua
-- Redis Lua script for sliding window rate limiting
local key = KEYS[1]
local now = tonumber(ARGV[1])
local window = tonumber(ARGV[2])
local limit = tonumber(ARGV[3])
redis.call('ZREMRANGEBYSCORE', key, 0, now - window)
local current = redis.call('ZCARD', key)
if current < limit then
redis.call('ZADD', key, now, now .. '-' .. math.random(100000))
redis.call('PEXPIRE', key, window)
return {1, current + 1}
end
return {0, current}
Try that with Memcached and you're building a distributed lock manager on top of a cache. Bad idea.
Pub/Sub and Eventing
If any part of your system needs pub/sub semantics for cache invalidation or event propagation, Redis handles it natively. In 2024 we built a feature where cache invalidation on one node needed to trigger a refresh on another. Redis pub/sub did this in 15 minutes. With Memcached, we'd have needed Kafka or a Redis instance anyway — at which point, why are we maintaining two systems?
Persistence: The Safety Net
This is controversial, but hear me out.
Memcached is ephemeral. Run out of memory, restart the process, crash — everything disappears. If your cache holds session data or critical lookups, a full cache flush can be disastrous.
Redis gives you options: RDB snapshots at scheduled intervals, AOF for append-only log replay, or both. You don't have to enable persistence for a pure cache, but you can. For anything session-adjacent, I recommend at least AOF with appendfsync everysec. The performance hit is negligible for most workloads, and you get the ability to recover a cache population that would otherwise take down your origin servers.
The "Both" Pattern Nobody Tells You About
You don't have to pick. In fact, if infrastructure allows it, using Memcached in front of Redis is a legitimate pattern that people rarely discuss when they're Googling "when to use redis vs memcached for caching."
Here's the reasoning:
- Memcached for high-throughput, low-complexity reads where you don't need atomicity (HTML fragments, pre-rendered templates, static lookups)
- Redis for anything that needs atomic operations, data structures, or pub/sub
I've seen this work in production at a health-tech company in 2025. They had a single Memcached cluster handling 3M ops/sec serving cached medical reference lookups, and a Redis cluster handling user sessions with atomic refresh token rotation.
Both tools were doing exactly what they're best at, and they never competed for the same workload.
The operational cost was higher — two systems to monitor, two sets of alerts. But each was individually simpler than a heavily-loaded Redis cluster trying to do everything, and the failure modes were isolated.
If you already have both in your environment, segment workloads and use each where it fits. You don't need to standardize on one.
Operational Considerations That Will Bite You
You don't realize how much operational overhead matters until it's 3 AM and your caching layer is down. Both tools have sharp edges.
Memory Management Differences
Memcached uses slab allocation. Allocate values of varying sizes and you get memory fragmentation. Small values fill up small slabs; bigger values use larger ones. If your value sizes vary wildly, you end up with wasted memory in one slab class while another slab class is full.
Redis stores everything in a single allocator (jemalloc or libc). It handles variable-sized values more gracefully. But Redis has its own issue: if you store huge values, you'll fragment the heap, and because Redis is largely single-threaded for command execution, a slow command can block everything else.
The trick I've learned: Redis with maxmemory-policy allkeys-lru and a target memory usage of 75-80% of physical RAM handles variable workloads far better than Memcached doing the same thing.
Monitoring
Memcached exposes stats and stats slabs. That's thin. By default, Memcached doesn't report hit rates or eviction rates that you'd want for alerting — you need to calculate those from raw counters.
Redis has a richer INFO command with cache hit/miss rates, eviction counts, memory fragmentation ratio, command statistics. Tools like RedisInsight give you a visual dashboard out of the box. For Memcached, you're building your own Grafana dashboards from counter exports, and the time series nature of those counters is your own responsibility.
If your team has limited SRE capacity, Redis wins by operational observability alone.
Scaling Differences
Memcached scales horizontally with consistent hashing (or a proxy like Mcrouter from Facebook). Adding nodes doesn't require key redistribution if you use client-side consistent hashing.
Redis supports clustering (officially for cache use cases with redis-cluster) and master-replica setups. But Redis Cluster has a hard 16,384 hash slot constraint, not a clean hash ring. If a node is down, keys that hash to its slots are unavailable — no automatic fallback to replicas unless you set up replica migration and read replicas carefully.
For pure vertical scaling, Memcached on a big box with many cores beats Redis on a comparable box, unless you configure Redis I/O threads properly. Most people don't. The official Redis docs cover threading setup here.
Making the Call: A Decision Framework
I've given you a lot of nuance. Let me compress it into a decision path that I use when talking to clients.
Ask yourself these questions in order:
1. Do you need atomicity on data structures beyond counters?
If you need sorted sets, hashes with atomic multiple-field updates, or server-side scripts, Redis is your only choice. Memcached can't do it. Stop reading.
2. Do you need persistence for any use case?
Session data that must survive a process restart? Pub/sub messages that need replay? Redis. Memcached loses everything.
3. Do you need pub/sub for cache invalidation or event distribution?
Redis. Memcached doesn't do this at all.
4. Is your workload purely "cache arbitrary serialized objects"?
Now Memcached becomes a real option. Simple GET/SET with local or distributed eviction. Thread scaling works out of the box.
5. How much latency is truly acceptable?
This is where I make a bold claim. At SIVARO we've tested both extensively. The difference between Memcached and Redis for identical GET workloads is consistently under 5% in real-world deployments. The Redis benchmark page itself shows Redis hitting 100K+ ops/sec per core, and Memcached is in the same order of magnitude.
Latency is rarely the deciding factor if your network stack adds more than a millisecond anyway.
6. What does your existing skill set look like?
This is the least technical but most important question. I've seen teams adopt Redis, misconfigure it, and get burned by out-of-memory errors because they didn't set maxmemory with a policy. Memcached has fewer knobs that can hurt you.
If you don't have someone who deeply understands Redis, Memcached might genuinely be the safer choice despite all of Redis's capabilities.
A Word on Cost
I don't consider this a major factor, but it gets discussed often. Both Redis and Memcached are open source. Neither charges per-seat licensing. Redis has enterprise layers (Redis Cloud, RediSearch, RedisJSON) that cost money, but the core in-memory store is free.
Memcached's ecosystem is more fragmented. Most client libraries are community-maintained and work. The operational tools are thinner.
If you're running managed services (ElastiCache, Redis Cloud, Memorystore), costs are roughly comparable for the same instance size. AWS's ElastiCache pricing has both Redis and Memcached at nearly the same node prices. The cost difference becomes about features and operational convenience vs. raw node cost.
At our scale, Redis's additional features saved us from running two more services (a pub/sub broker and a rate limiter), meaning lower total infra spend despite Redis being "more expensive" per node.
The Verdict
When to use redis vs memcached for caching boils down to this:
-
Choose Memcached when you're building a pure cache, you want zero persistence concerns, your value sizes are moderate, and you value a dead-simple multi-threaded design that doesn't get in your way.
-
Choose Redis when your "cache" has responsibilities beyond GET/SET: atomic operations, data structures, pub/sub, or the possibility that future features will need those.
-
Choose both if you have a diverse workload and can monitor both.
Most teams should default to Redis. Not because Redis is always better, but because most application architectures eventually need something else from their caching layer: rate limiting, session atomicity, or a leaderboard. And the cost of migrating from Memcached to Redis when you hit that wall dwarfs the savings of starting with Memcached.
I'm not saying Memcached is dead. It's far from it. If you've built a stateless read-through cache and you know exactly what you need, Memcached is genuinely lighter to operate.
But if you're reading this unsure which way to go, and you've got more than a week of roadmap ahead of you, choose Redis.
Your future self will thank you when the "feature request" for distributed rate limiting shows up on Monday.
Frequently Asked Questions
Is Redis faster than Memcached for basic GET/SET?
No, not meaningfully. On real-world deployments, the difference is under 5% for simple GET/SET workloads. Performance differences are mostly hardware-dependent and irrelevant compared to other operational factors.
Can Memcached handle session storage?
Technically, yes — if sessions are purely "store token and retrieve user ID on every request." But the moment you need atomic expiration updates, sliding sessions, or session revocation events, Memcached hits its ceiling. For anything beyond trivial sessions, Redis is better.
Does Redis persistence affect cache performance?
AOF persistence with appendfsync everysec adds roughly 1-2% CPU overhead in our tests at SIVARO. With appendfsync always, that jumps to 10%+, which is a real cost. RDB snapshots (background saves) have minimal throughput impact but memory usage spikes during the fork.
Can I run Redis Cluster for cache only?
Yes, but I'd recommend against it for pure cache workloads unless you need automatic failover. Redis Cluster's hash slot distribution works, but if any node fails, you must retrieve keys from that node's replicas or they're gone. For pure cache, setup is more complexity than value. Run standalone Redis with maxmemory-policy allkeys-lru.
Which client libraries should I use?
For Redis, use redis-py (Python), ioredis (Node), lettuce (Java), or redis-client (Go). For Memcached, use python-memcached (Python) or mcrouter (C++ if you need proxy capabilities). Check for your language's official docs.
What are the best open source tools for monitoring both?
Prometheus + Grafana works for both. Redis exposes many metrics via INFO. Memcached requires you to parse stats and calculate rates yourself. Redis Insights gives out-of-box dashboards; Memcached doesn't have an equivalent.
Is AWS ElastiCache a good idea for this?
ElastiCache gives you managed Redis or Memcached. It's solid for both. With Redis you get backups, Multi-AZ failover, and monitoring out of the box. With Memcached you get automatic node replacement but no persistence. If you're on AWS, ElastiCache Redis makes the choice easier because it eliminates much of the operational overhead that makes Redis harder to run yourself.
The Bottom Line
Stop benchmarking and start designing.
The question of when to use redis vs memcached for caching isn't really about latency or memory efficiency. Both tools are fast enough. Both handle millions of ops per second.
Choose Memcached if you've built a cache that does one job, does it well, and nothing else. Choose Redis if your caching layer carries other responsibilities — or will carry them soon because all software grows in complexity.
Every time I've seen a team hit the "Memcached isn't enough" wall, the migration wasn't just adding a new service. It was rewriting application logic, testing edge cases around atomic operations, and explaining to the CTO why we need to change something that "was already working."
Think about what your system is becoming, not just what it is today.
If you're still uncertain, ship Redis. The odds are better that you'll need its features before your roadmap is over.
Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.