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.

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

How much does this cost

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. The Redis traffic dropped meaningfully. The application latency on configuration reads went from a few milliseconds to nanoseconds. The Redis bill dropped slightly. The application got slightly simpler because the configuration access path no longer required network calls.

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.