Redis or Memcached for WordPress on a VPS: differences and step-by-step setup

Anyone running a WordPress VPS with real traffic eventually hits the same wall: full-page caching alone is no longer enough, because logged-in users, WooCommerce shopping carts and restricted areas cannot be served from a static page. This is where object-level caching comes in—the kind that intercepts repeated queries to wp_options, wp_postmeta and similar tables before they reach the database. The two backends that implement it are Redis and Memcached. They are not interchangeable without trade-offs: here's what actually changes and how to install them on Ubuntu 24.04.

The differences that matter, not the brochure ones

On a single host, for the traffic generated by a WordPress request, the two caches are essentially indistinguishable in terms of pure speed. For a WordPress site that needs persistent object caching, Redis is the right default choice—not because it is faster, but because the Redis drop-ins are actively maintained whilst the Memcached ones are not.

The concrete technical differences:

Feature	Redis	Memcached
Persistence across reboot	Optional (RDB/AOF)	No, restarts empty
Data structures	Strings, lists, hashes, sets	Key-value only
Maximum element size	Up to 512 MB	1 MB by default
Logical databases to isolate sites	Yes, numbered	No
Threading	Single-threaded commands	Multithreaded
Default port	6379	11211

Memcached's 1 MB limit becomes an issue when a plugin writes a value larger than that threshold: Memcached discards it and WordPress falls back to the database for one of the most frequent queries. On a site with many active plugins or WooCommerce, this is a real risk. On the multi-site front, Redis supports numbered logical databases that let each site have its own isolated namespace, something Memcached does not offer.

On process restart: if Memcached is restarted, the cache disappears and starts empty, refilling over time. It is not an operational disaster—the database can still handle the load—but on a heavily trafficked site it means a few minutes of higher load immediately after any deployment or service restart.

Installing Redis on Ubuntu 24.04

The package is already in the official Ubuntu repositories:

sudo apt update
sudo apt install redis-server
redis-server --version
sudo systemctl enable --now redis-server
sudo systemctl status redis-server

If you need a more recent version than the one packaged by Ubuntu, Redis Ltd maintains a separate APT repository. The official command adds the GPG key and the packages.redis.io repository, then installs via apt-get install redis, which brings the latest stable version instead of the frozen one in system repositories.

You also need the PHP extension to make WordPress talk to Redis:

sudo apt install php-redis
sudo systemctl restart php8.3-fpm

(replace php8.3-fpm with the version of PHP-FPM actually in use on your VPS).

For a production server, beyond installation you need to set a memory limit and an eviction policy, otherwise Redis can fill all available RAM: install Redis at the system level, set maxmemory to a fixed value based on your host's RAM budget, and set maxmemory-policy to allkeys-lru. These two lines go in /etc/redis/redis.conf and then restart the service with sudo systemctl restart redis-server.

Installing Memcached on Ubuntu 24.04

sudo apt update
sudo apt install memcached
sudo systemctl enable --now memcached
sudo apt install php-memcached
sudo systemctl restart php8.3-fpm

Pay attention to a detail that many guides skip: the official WordPress plugin, "Memcached Object Cache", does not use the modern php-memcached extension but the legacy one. Looking at the plugin page on WordPress.org shows that it requires a memcached server and the PECL memcache extension—note the class name written without the final "d", the legacy one, not the libmemcached-based library that you normally install via apt today. The same plugin, at time of writing, is stuck at version 4.0.0, last updated 4 years ago, with 10+ active installations and tested up to WordPress 6.1.15: numbers that signal an under-maintained project, one to verify case by case before trusting it with a production site.

Configuring the object-cache plugin for WordPress

With Redis

1. Install the "Redis Object Cache" plugin (by Till Krüss) from the WordPress plugin dashboard or from the command line with WP-CLI: wp plugin install redis-cache --activate.
2. Add to wp-config.php, before the line "That's all, stop editing":

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);

3. Enable caching from Settings → Redis panel by clicking "Enable Object Cache", or from the terminal with wp redis enable.

On a server hosting multiple WordPress installations, also add the WP_REDIS_DATABASE variable to assign each site a different logical database number (0 to 15 by default), preventing a flush on one site from clearing the cache of others.

With Memcached

1. Manually copy the plugin's object-cache.php file into the site's wp-content/ folder: the installation steps involve installing memcached on at least one server, noting the connection details, installing the PECL memcache extension and copying object-cache.php to wp-content.
2. Add to wp-config.php the constant WP_CACHE_KEY_SALT with a unique random string: this helps prevent cache pollution when multiple WordPress installations share the same Memcached server, and the value must be unique for each installation.

Verifying that caching is truly active

Just seeing the plugin "active" in the dashboard is not enough: you need to check that WordPress is actually writing to and reading from the external cache.

• From the command line, with Redis: redis-cli monitor shows GET/SET commands in real time as you navigate the site in another tab. If the list remains empty, the drop-in is not loaded.
• Also with Redis: wp redis status (via WP-CLI) returns the connection status and the type of client used (PhpRedis, Predis or Relay).
• Check that the wp-content/object-cache.php file actually exists: it is a drop-in copied from the plugin, not a file that appears automatically when activating the plugin from the dashboard.
• For Memcached, memcached-tool 127.0.0.1:11211 stats shows the number of get/set operations and the cache hit percentage.
• A debug plugin like Query Monitor adds an "Object Cache" tab with the number of queries saved and the detected backend type: this is the quickest way to see the effect without opening a terminal.

If after enabling the plugin the number of database queries in the admin page remains identical to before, the cause is almost always either the missing object-cache.php file in wp-content/ or a connection error to the wrong port (6379 for Redis, 11211 for Memcached).