blog posts

If you run a database-driven website — WordPress, Drupal, Magento, a custom Laravel app — you have probably hit the same wall. The site feels fine with ten visitors and grinds to a crawl with a thousand. Page caching helps, right up until logged-in users show up and every request becomes uncacheable again.

Redis Object Cache is the tool most teams reach for at that point. It is not a magic speed switch, and it does not replace a CDN or page cache. But for the specific problem of “my database is doing the same work over and over,” it is close to the ideal fix.

Here is what it actually is, how it works, and when it is worth setting up.

Start with the object cache.

Before Redis enters the picture, you need to understand what an object cache is on its own.

Every time someone loads a page on your site, your application runs dozens — sometimes hundreds — of database queries. It fetches site settings. It fetches the current user’s data and permissions. It fetches the posts for this page, the tags on those posts, the menu structure, the widget configuration, the active plugin list. Most of that data is identical to what it fetched on the last request and the request before that.

An object cache is a key-value store that sits between your application and the database. The first time the app needs a piece of data, it queries the database and stores the result in the cache under a key. Every subsequent request checks the cache first. If the data is there — a cache hit — the database never gets touched.

WordPress ships with an object cache built in. The catch is that by default it is non-persistent: it only lives for the duration of a single page load. As soon as PHP finishes rendering the page, the cache is thrown away. The next visitor starts from zero.

That is the gap Redis fills.

Where Redis comes in

Redis (Remote Dictionary Server) is an in-memory data store. It holds data in RAM rather than on disk, which makes reads and writes extremely fast — typically well under a millisecond. It runs as a separate service on your server, or on a dedicated machine, and your application talks to it over a network socket.

Redis Object Cache is simply the combination of the two ideas: using Redis as the storage backend for your application’s object cache, so that cached data survives between requests.

Now when visitor A triggers a query for your site’s option table, the result gets stored in Redis. When visitor B arrives thirty seconds later, that data is already sitting in memory. The query never runs. Multiply that by a few hundred queries per page and a few thousand page views per hour, and the reduction in database load is substantial.

This is what people mean by a persistent object cache. “Persistent” here refers to persisting between requests, not to durability on disk.

What a request looks like with Redis in place

The flow is straightforward:

1. A visitor requests a page.
2. Your application needs a piece of data — say, the list of categories.
3. It asks Redis for the key. site:categories:all.
4. Cache hit: Redis returns the data in a fraction of a millisecond. Done.
5. Cache miss: The application queries MySQL, gets the result, writes it into Redis with an expiry time, and returns it.
6. When that data changes — someone adds a category — the application invalidates or overwrites the key so nobody serves stale content.

Step six is the part that trips people up, and it is worth saying plainly: a cache is only as good as its invalidation. Good integrations handle this automatically. Poor ones leave you with a site that shows yesterday’s prices.

What it actually speeds up

Redis Object Cache is most valuable for dynamic, uncacheable requests. Specifically:

• Logged-in users. Page caches usually bypass logged-in traffic entirely because every user sees something different. Object caching still works here, because the underlying data — settings, taxonomies, product catalogs — is shared.
• Admin dashboards. Anyone who has watched a WordPress admin panel crawl on a large site knows the problem. Object caching helps considerably.
• WooCommerce and other e-commerce. Carts, sessions, and product lookups are dynamic by nature.
• Membership sites, forums, LMS platforms. Anywhere personalized content dominates.
• High-traffic sites generally. Even with a page cache, the misses and the cache-warming requests still hit the database.

It is less transformative for a small brochure site serving mostly anonymous visitors from a full-page cache. There, the database is barely under strain to begin with.

Object cache vs page cache: not the same thing

This confusion is common enough to deserve its own section.

A page cache stores the finished HTML of a page. When a request comes in, the server hands back the stored HTML without running PHP or touching the database at all. It is the fastest possible option — and completely unusable for personalized content.

An object cache stores the individual ingredients: query results, computed values, API responses. PHP still runs, and the page is still assembled fresh, but the expensive lookups are skipped.

They are complementary, not alternatives. A well-tuned site typically runs a CDN, a page cache, an object cache, and a properly indexed database. Each layer catches what the one above it could not.

Redis vs Memcached

Memcached is the other established object cache backend, and for pure key-value caching the two perform similarly. Redis tends to win on capability:

• Richer data types. Lists, sets, sorted sets, and hashes rather than just strings.
• Optional persistence to disk. Redis can snapshot to disk and reload after a restart, so a reboot does not cold-start your cache.
• Replication, clustering, and Sentinel for high availability.
• Pub/sub and atomic operations, useful well beyond caching.

Memcached is simpler and has genuinely excellent multi-threaded performance for straightforward workloads. But most teams choose Redis because they end up wanting it for sessions, queues, or rate limiting anyway, and running one service beats running two.

Setting it up

The details vary by platform, but the shape is always the same.

1. Install and run Redis. On managed hosting, this is often a toggle in your control panel. Many hosts — particularly those using cPanel or a custom dashboard — expose Redis as a one-click feature. On a VPS, you install it via your package manager and start the service.

2. Install a PHP extension. PhpRedis (a C extension) is the fastest option. Predis is a pure-PHP fallback that works anywhere but is slower. Relay is a newer commercial option that adds an in-process memory layer on top.

3. Connect your application. For WordPress, the standard choice is the Redis Object Cache plugin, which installs a object-cache.php drop-in file that replaces WordPress’s built-in cache with a Redis-backed one. Alternatives include WP Redis from Pantheon, Object Cache Pro (commercial), and the object-cache modules bundled into W3 Total Cache and LiteSpeed Cache. Run only one of these at a time — stacking them causes conflicts.

4. Configure credentials. Host, port (6379 by default), password, and database index typically go in wp-config.php your framework’s environment file. Set a unique cache key prefix if multiple sites share one Redis instance; otherwise, they will overwrite each other’s data.

5. Verify. Any decent integration shows a connection status and hit-rate diagnostics. Confirm the status reads “Connected” and the drop-in is valid before you assume it is working.

Things that go wrong

A few pitfalls worth knowing about in advance:

Memory limits and eviction. Redis holds everything in RAM. Set maxmemory and an eviction policy — allkeys-lru is the sensible default for a pure cache. Without one, Redis will happily consume all available memory.

Security. Never expose Redis to the public internet. Bind it to localhost or a private network, set a strong password, and consider renaming or disabling dangerous commands. Unsecured Redis instances are a well-known target.

Shared hosting. Redis is frequently unavailable on cheap shared plans, or shared across so many accounts that the benefit evaporates.

Stale data. Suppose you see content that will not update; flush the cache first before debugging anything else. It is the answer more often than not.

Long-running scripts. Bulk imports, cron jobs, and WP-CLI commands can flood the cache with data nobody will read. Many teams disable object caching for those specific processes.

A note on Redis and Valkey

Redis changed its license in March 2024, moving away from the permissive BSD license. The community responded by forking the last BSD version into Valkey, now maintained under the Linux Foundation. Redis subsequently added AGPLv3 as an option in Redis 8.

For most site owners, this is background noise — Valkey is wire-compatible, so the same clients and plugins work against either. It matters mainly if you are building a commercial product on top of the engine, where the license terms differ meaningfully.

Is it worth it?

If your site serves logged-in users, runs e-commerce, or handles meaningful traffic, a persistent object cache is one of the highest-return optimizations available. Database load drops, admin work stops feeling sluggish, and the same server handles more concurrent visitors.

If you run a small static site behind a good page cache, spend your effort elsewhere first — image optimization, a CDN, and a decent host will do more.

Measure before and after. Watch query counts and time-to-first-byte.

FAQ