Redis vs Memcached: choosing an object cache for your server

If your application asks the database the same questions on every request, an in-memory cache can take most of that load off. Redis and Memcached are the two usual choices. Both are fast, free and mature. For most applications today the answer is Redis, but it is worth knowing why, and when Memcached still makes sense.

What an object cache does

Applications like WordPress, Magento, Laravel and Django repeat a lot of work: loading settings, checking permissions, looking up products. An object cache keeps those results in memory so the database is not asked twice.

That is different from page caching, which stores whole rendered pages. Page caching helps anonymous visitors. Object caching helps everything a page cache cannot serve: logged-in users, admin dashboards, carts, APIs. Most busy sites benefit from both.

It makes the biggest difference for:

• slow admin areas, which are never page-cached;
• applications with many plugins or modules, each adding queries;
• stores with large catalogs, where product and category lookups dominate.

How they compare

When to choose Redis

Choose Redis for almost everything:

• It survives restarts. With persistence on, a reboot does not leave the database facing a cold cache and a sudden traffic spike.
• It does more than cache. Laravel queues, Django sessions, rate limiters and job locks can all share it, so you run one service instead of three.
• Ecosystem support. Most frameworks and CMS plugins treat Redis as the default.

When Memcached still fits

Memcached is simpler and multi-threaded. If you need a very large, purely volatile cache of simple values spread across many CPU cores, and nothing else, it is a reasonable choice. It is also fine to keep an existing, working Memcached setup rather than migrate for the sake of it.

Install Redis on Ubuntu

apt update && apt install -y redis-serversystemctl enable --now redis-serverredis-cli ping

PONG means it is running.

Size it and set an eviction policy

Edit /etc/redis/redis.conf:

maxmemory 256mbmaxmemory-policy allkeys-lru

Without a memory limit, Redis grows until the server runs out of RAM. allkeys-lru evicts the least recently used keys when the limit is reached, which is what you want for a cache. If you also use Redis for queues or sessions you cannot afford to lose, use volatile-lru and set expiry times on cache keys only.

systemctl restart redis-server

Keep it private

Redis should never be reachable from the internet. Ubuntu's package binds to localhost by default; confirm it:

ss -tlnp | grep 6379

You want 127.0.0.1:6379, not 0.0.0.0:6379. If an app on another server needs access, the safest route is an encrypted tunnel between the two (WireGuard, or an SSH tunnel). If you must listen on the network, set a password and allow only that one host through the firewall:

bind 127.0.0.1 203.0.113.10requirepass a-long-random-password

ufw allow from 203.0.113.25 to any port 6379 proto tcp

Connect your application

Install the PHP extension and point your app at it, for example in Laravel's .env:

apt install -y php-redis

CACHE_STORE=redisSESSION_DRIVER=redisREDIS_HOST=127.0.0.1

For WordPress, an object cache plugin such as Redis Object Cache connects with the same host and port.

See it working

redis-cli info stats | grep -E 'keyspace_(hits|misses)'

A rising hit count, and a hit rate well above the miss rate after warm-up, means the cache is doing its job.

Next steps

• Give the cache more memory headroom on a larger Cloud Server plan.
• Move the database itself to a Managed Database.
• Compare CPU options for busy apps on Pricing.