Memcached vs Redis: how to choose a cache for your web app

Adding a cache is often the cheapest way to make a slow web app feel fast. Instead of hitting the database for the same query on every request, you store the result in memory for a short time. The first question is which cache to use. For most small products, the answer is simpler than the comparison charts suggest.

Decide what you actually need to cache

Write down what goes into the cache and what happens if it disappears. Query results, rendered page fragments, API responses, and session data are the usual candidates. If the app still works correctly when the cache is empty, just slower, you need a cache. If losing the data would lose customer state, you need a database with caching features, and the choice changes.

When Memcached is the right choice

Memcached is an open-source, in-memory key-value store built to speed up dynamic web apps by taking load off the database. It stores small chunks of data as strings or serialized objects, evicts the least recently used items when memory fills up, and is multithreaded, so one node can use several CPU cores.

• You cache values by key and rebuild them from the database on a miss.
• You do not need data to survive a restart.
• You want the smallest set of concepts to learn and operate.
• Your framework already has a Memcached client, which most major languages and frameworks do.

When Redis or Valkey earns the extra features

Redis goes beyond strings. It supports lists, sets, sorted sets, hashes, and more, plus snapshots and an append-only file for persistence, replicas for high availability, transactions, Lua scripting, and pub/sub messaging. That makes it useful for leaderboards, rate limiters, queues, and real-time features, not only caching.

Licensing is worth a look. Redis moved away from its original BSD license, and Redis 8 Community Edition is available under AGPLv3 among other options. Valkey is a BSD-licensed fork backed by the Linux Foundation and compatible with Redis OSS clients. Many managed providers now offer Valkey. Memcached remains BSD-licensed.

Check the managed service before you commit

Running a cache yourself is easy until it is not: upgrades, monitoring, memory sizing, and failover all land on you. A managed cache removes that work, but pricing and setup vary a lot.

1. 1Pricing model: per node-hour, per memory tier, or per request. Estimate your real memory need first.
2. 2Region: keep the cache close to your app servers, and in the EU if your data must stay there.
3. 3Network setup: some clouds require a private network before you can connect.
4. 4Visibility: hit rate, evictions, and latency percentiles tell you whether the cache is doing its job.
5. 5Access control: separate credentials per environment keep a test script from flushing production.

Velstash Cache: a managed Memcached instance hosted in Europe

Velstash Cache offers dedicated managed Memcached instances priced by memory size, hosted in France and Finland. There is a 100MB free instance without a credit card, and the company positions its monthly plans as cheaper than AWS ElastiCache, Azure Cache, and GCP Memorystore.

The dashboard shows hit rate, memory use, evictions, and P50, P90, and P99 read and write latency, plus a per-key and per-prefix breakdown of hits and misses. It also supports alerts and separate credentials per environment. It fits a small team that wants a working Memcached endpoint without cluster setup; compare the plan against your measured memory use.

Measure the hit rate after launch

A cache that rarely hits is just extra latency. After a week, check the hit rate and evictions. A low hit rate usually means keys are too specific or expire too soon. Frequent evictions mean the cache is too small for the working set. Adjust one thing at a time and measure again.