Every WordPress page load runs dozens of database queries. Options, user meta, transients, post data – the same stuff gets fetched over and over. That’s where the WordPress object cache comes in. It stores query results in memory so WordPress doesn’t have to hit the database every single time.
But here’s what most “Redis vs Memcached” articles get wrong – they jump straight to the comparison without explaining what the object cache actually does. So let’s fix that.
What the WordPress Object Cache Actually Does
WordPress has a built-in object cache. It’s been there since version 2.5. Every time WordPress fetches an option, loads post meta, or grabs user data, it stores the result in a PHP array using wp_cache_set(). The next time that same data is needed during the request, it calls wp_cache_get() and grabs it from memory instead of running another SQL query.
Here’s the thing most people miss – the default object cache only lives for one request. When the page finishes loading, all that cached data is gone. The next visitor triggers the same queries all over again.
That’s the default behavior. No plugin needed. WordPress does it out of the box.
Where It Gets Interesting
A persistent object cache changes the game. Instead of storing data in a PHP array that dies with the request, it stores it in an external memory store – like Redis or Memcached. Now that cached data survives between requests. Visitor A loads the homepage and populates the cache. Visitor B gets the cached version without touching the database at all.
The mechanism is a WordPress “drop-in” – a special file called object-cache.php placed in wp-content/. WordPress checks for this file on every request. If it exists, WordPress uses it instead of the default WP_Object_Cache class. That’s how Redis or Memcached plugins hook into the system.
When You Actually Need a Persistent Object Cache
Not every site needs one. Here’s when it matters:
You probably need it if:
- Your site runs WooCommerce or a membership plugin with logged-in users (page cache doesn’t help much for authenticated requests)
- You have a high-traffic site with complex queries – especially dynamic pages that can’t be page-cached
- Your admin dashboard is slow – object cache dramatically speeds up the backend
- You’re seeing hundreds of database queries per page load
You probably don’t need it if:
- You run a simple blog with mostly anonymous visitors and a page cache plugin
- Your hosting doesn’t support Redis or Memcached (shared hosting often doesn’t)
- You have fewer than 1,000 daily visitors and no complex plugins
The key insight is that object cache complements page cache – it doesn’t replace it. Page cache serves complete HTML pages. Object cache reduces database queries for content that can’t be page-cached. If you’re curious about what’s actually slowing down your queries, check out how to find and fix slow WordPress queries.
Redis vs Memcached: The Real Differences
Ok, the comparison everyone came for. I’m not going to fabricate benchmark numbers – the raw speed difference between Redis and Memcached is negligible for WordPress object caching. Both operate in microseconds. What matters are the architectural differences.
Data Persistence
Redis can persist data to disk. If your Redis server restarts, the cache can be restored from the last snapshot. Memcached is purely in-memory – restart it and everything is gone.
For WordPress, this matters less than you’d think. A cold cache rebuilds itself within a few page loads. But if you’re running a large WooCommerce store with millions of cached keys, a warm restart is nice to have.
Data Structures
Redis supports strings, lists, sets, sorted sets, hashes, and more. Memcached is strictly key-value with string values.
For basic WordPress object caching, this difference is mostly irrelevant – WordPress stores serialized PHP data as strings either way. But if you’re building custom functionality that uses the cache directly, Redis gives you more flexibility.
Memory Management
Memcached uses a slab allocator. It pre-allocates memory in chunks and assigns items to the closest matching slab size. This is efficient but can waste memory when your cached items vary wildly in size.
Redis allocates memory on demand using standard system allocators (jemalloc by default). More flexible, but can fragment over time.
Both let you set a maximum memory limit. Both evict old keys when they hit the limit. Redis gives you more eviction policies to choose from (LRU, LFU, random, volatile-based).
Replication and High Availability
Redis has built-in replication. You can set up Redis Sentinel for automatic failover or use Redis Cluster for horizontal scaling. Memcached has no native replication – you’d need external tools.
For most WordPress sites, this is overkill. But if you’re running a high-availability setup behind a load balancer, Redis makes the infrastructure simpler.
Observability
Redis wins here. You can inspect keys, check memory usage per key, monitor commands in real-time with MONITOR, and get detailed stats with INFO. Memcached’s stats command gives you the basics but you can’t easily peek at individual keys or their sizes.
When you’re debugging why your object cache is eating 512MB of RAM, Redis makes the investigation much easier.
WordPress Plugin Ecosystem
Redis has better WordPress plugin support. Object Cache Pro (paid) and Redis Object Cache (free) are both mature and well-maintained. For Memcached, the options are more limited and less actively developed.
Quick Comparison
| Feature | Redis | Memcached |
|---|---|---|
| Data persistence | Yes (RDB/AOF) | No |
| Data structures | Strings, lists, sets, hashes, etc. | Strings only |
| Replication | Built-in (Sentinel, Cluster) | None (needs external tools) |
| Memory efficiency | Good, can fragment | Good, slab allocator |
| Max memory eviction | 6 policies (LRU, LFU, etc.) | LRU only |
| Key inspection | Full (SCAN, DEBUG OBJECT) | Limited |
| Multi-threaded | Single-threaded (I/O threads in 6.0+) | Multi-threaded |
| WordPress plugins | Excellent (Object Cache Pro, Redis Object Cache) | Limited |
My Recommendation
Use Redis. Not because it’s faster for basic key-value operations – it’s not meaningfully different. But because the ecosystem is better, the debugging tools are better, and the WordPress plugin options are better maintained.
The only scenario where I’d pick Memcached is if it’s already running and working on your server and you don’t want to touch the infrastructure. If you’re setting up from scratch, Redis is the way to go.
How to Verify Your Object Cache Is Working
Installing a Redis plugin and hoping for the best isn’t enough. You need to verify it’s actually doing something.
Check the Drop-In Status
In WP admin, go to Plugins > Drop-ins. You should see object-cache.php listed there. If it’s missing, the persistent cache isn’t active – regardless of what your caching plugin says.
You can also check via WP-CLI:
wp cache typeThis should return something like Redis or Memcached. If it says WP_Object_Cache, you’re running the default non-persistent cache.
Check Hit Rates
A healthy object cache should have a hit rate above 85%. If you’re seeing lower numbers, something is wrong – either the cache is too small, keys are expiring too fast, or a plugin is flushing the cache constantly.
With Redis, you can check from the command line:
redis-cli INFO stats | grep keyspaceThe keyspace_hits and keyspace_misses numbers tell you the real story. Calculate: hits / (hits + misses) * 100.
Use WP Multitool’s Cache Analyzer
WP Multitool includes a cache analyzer that shows you exactly what’s being cached, how much memory each group uses, and your hit/miss ratio. It’s useful for finding plugins that abuse the object cache or store way too much data. It also flags when your autoloaded options are filling up the cache with data that shouldn’t be there.
Common Gotchas
I’ve seen these issues come up over and over. Save yourself the debugging.
1. The object-cache.php Conflict
Only one object-cache.php drop-in can exist at a time. If you install Redis Object Cache but you already have a Memcached drop-in, or if a managed hosting provider has their own drop-in, you’ll get conflicts. The WordPress Performance Lab plugin has documented this issue – when multiple plugins try to manage the same drop-in file, things break silently.
Before installing any object cache plugin, check if wp-content/object-cache.php already exists and who put it there.
2. Memory Limits Too Low
The default Redis maxmemory is often 64MB. For a WooCommerce store or a site with lots of plugins, that fills up fast. When it does, Redis starts evicting keys, your hit rate tanks, and you’re back to hammering the database.
Set a realistic memory limit. For most WordPress sites, 128-256MB is a good starting point. Monitor usage and adjust.
3. SAVEQUERIES and WP_DEBUG in Production
This is a sneaky one. If WP_DEBUG or SAVEQUERIES is enabled, Object Cache Pro and similar plugins will store backtraces for every cache operation. This is incredibly memory-intensive and can cause PHP fatal errors from memory exhaustion. Never run these in production.
Check your wp-config.php – make sure both are false on production.
4. Plugins Flushing the Cache Constantly
Some plugins call wp_cache_flush() way too aggressively. Every time the cache is flushed, everything has to be rebuilt from the database. I’ve seen plugins that flush the entire object cache on every post save.
If your cache hit rate is suspiciously low, this is likely the cause. You can monitor Redis commands to catch the culprit:
redis-cli MONITOR | grep FLUSHDBThen trace back which plugin is triggering it.
5. Transients Behavior Changes
Here’s something most people don’t know – when you install a persistent object cache, WordPress stops storing transients in the database. Instead, they go to the object cache. This is usually a good thing (less database bloat), but it means transients are now subject to cache eviction. If you have plugins that rely on transients persisting for days, they might break when Redis evicts them under memory pressure.
6. Serialization Overhead
WordPress serializes every object before storing it in the cache. For large objects – like a complex WP_Query result with 500 posts – the serialization/unserialization cost can actually be higher than just running the query again. This is rare, but worth knowing if you’re caching custom data.
The “Do Nothing” Option
Here’s the part most articles skip. Sometimes the best object cache is no persistent object cache at all.
The default WordPress object cache still works within each request. If your site is mostly anonymous visitors with a page cache serving 95% of requests, adding Redis complexity might not be worth it. The pages that bypass the page cache (admin, AJAX, WP-Cron) might not generate enough database load to justify another service in your stack.
Start by looking at your actual database query count and load. If you’re seeing 50-80 queries per page and your database server isn’t stressed, you might not need Redis at all. Focus on optimizing your database first – clean up bloated tables, fix missing indexes, reduce autoloaded data.
Object cache is a tool, not a requirement. Use it when the data tells you it’s needed.
Join developers and agency owners who get backend optimization strategies, tool releases, and deep-dive guides.
No spam. Unsubscribe anytime. We respect your privacy.