Choosing a Cache: Redis vs Memcached vs In Memory

What you actually need to know

• In memory cache wins for small per process data that rarely changes.
• Memcached wins for pure key value at extreme scale.
• Redis wins for almost every other case.
• Managed Redis is the right starting point for most teams.
• Eviction policy and hit rate are the two metrics that matter most.

Cache type	Scope	Best fit
In memory	Per process	Config, feature flags, lookups
Memcached	Distributed key value	Extreme throughput pure KV
Redis	Distributed multi structure	Caching, queues, rate limit, leaderboards
Hybrid in memory plus Redis	Per process plus shared	Common in mature SaaS

The core argument

The cache choice is one of those infrastructure decisions that founders treat as solved by default. The team picks Redis because Redis is what they have heard of. The choice is often right, but the team rarely understands why. The wrong choice in specific cases produces real problems that the right understanding would have avoided.

In memory cache is underused. The pattern of loading configuration at process startup and refreshing every minute or two from the database is excellent. The cache is free. The cache is fast. The cache shares nothing across processes, which is fine because the data does not change often and brief inconsistency between processes is acceptable. The team that uses in memory cache for the right data saves Redis traffic and gets the lowest latency possible.

Memcached is the right call when the workload is pure key value at extreme scale and the team values throughput over features. The narrow specialization makes Memcached faster than Redis for that specific workload. Most teams do not have that workload. Most teams use Redis for everything and benefit from the operational simplicity of one cache server.

Redis is the right call when the cache also serves as a queue, a rate limiter, a session store, or any of the other roles Redis can play. The team gets one server that handles many use cases. The operational footprint is smaller than running multiple specialized systems.

The pattern that mature SaaS converges on is in memory cache for per process configuration plus Redis for shared cache and other Redis use cases. Memcached shows up in specific high throughput workloads. The combination covers most needs efficiently.

The decision by use case

Use case	Best cache
Configuration loaded at startup	In memory
Feature flags refreshed every minute	In memory
User session storage	Redis
API response caching	Redis or CDN
Rate limiting	Redis
Job queue	Redis
Leaderboard	Redis sorted set
Pure key value at high throughput	Memcached
Pub or sub messaging	Redis
Distributed lock	Redis

How much does this cost

Option	Monthly cost at moderate scale
In memory cache	Free
Managed Memcached on AWS ElastiCache	50 to 300 USD
Managed Redis on Upstash	Free to 200 USD
Managed Redis on Redis Cloud	100 to 500 USD
Managed Redis on ElastiCache	100 to 500 USD
Self managed Redis	Free to run, real to operate

Features the cache choice must have

• Appropriate eviction policy for the access pattern.
• Monitoring on hit rate, eviction rate, memory, latency.
• Connection pooling tuned to the application.
• TLS for connections that cross the network.
• Authentication enabled.
• Backup strategy if persistence is enabled.
• Capacity planning that anticipates growth.

Expert opinion

Most teams over rotate to Redis for everything and miss the cases where in memory cache would have been faster and free. The pattern of in memory for per process plus Redis for shared is the mature default. The teams that adopt it get the latency of in memory where it matters and the consistency of Redis where it matters. The choice is not Redis or nothing.

Yashveer Singh, founder of Yashveer Labs

How this played out on a real project

A client SaaS had Redis for every cache, including configuration loaded at startup. The Redis read traffic was significant. The latency on configuration reads was higher than it needed to be. The Redis bill was modest but real.

We moved the configuration cache in memory with a one minute refresh. Redis traffic dropped meaningfully, latency on configuration reads went from a few milliseconds to nanoseconds, and the bill dropped a little too. The application also got simpler, since that access path no longer needed a network call at all.

We kept Redis for everything that genuinely needed shared state. Session storage, rate limiting, job queue, certain cached API responses. The hybrid pattern fit the application better than the pure Redis pattern that had been in place.

For more on the related work, see caching strategies for growing SaaS from none to multi layer and the caching hierarchy browser CDN edge application database.

Common mistakes teams make

1. Using Redis for data that should be in memory.
2. Using in memory for data that needs to be shared across processes.
3. Default eviction policy that does not match the workload.
4. No monitoring. The cache silently fails.
5. Self hosting Redis without the operational appetite.
6. No connection pooling. Saturation at scale.
7. Mixing tenant data in the cache without tenant scoped keys.
8. Picking Memcached when Redis would have done.

A 30 day plan to pick the right cache

1. Week one. Inventory the data being cached. Classify each as per process or shared.
2. Week two. Move per process data to in memory cache. Keep shared on Redis.
3. Week three. Tune eviction policies. Set up monitoring.
4. Week four. Measure the impact. Tune connection pooling.

For more on the related work, read caching strategies for growing SaaS from none to multi layer and connection pooling the quiet killer of SaaS performance. On the broader infrastructure side, the database you did not think you needed when to add Redis Elasticsearch or ClickHouse is the natural next read.

FAQ

Frequently asked

• When is in memory cache enough?
• When does Memcached win over Redis?
• Why does Redis dominate?
• Should I use managed Redis?
• What about Redis persistence?
• What is the eviction policy and why does it matter?
• How do I monitor cache health?

Author

The reason I write these

I write these because the writing is the proof. Yashveer Singh, founder of Yashveer Labs. The systems I build are not theoretical. They are running right now, serving real users, generating real revenue. That is the bar I hold this writing to. If you want to hire someone who can match that bar, I am the call.

Start the conversation See the work DM on Instagram