Redis vs Memcached for WordPress Object Caching

Redis and Memcached can both reduce repeated database work in WordPress by providing a persistent backend for the object cache.

The right choice is not simply “which one is faster.” It depends on:

• Your WordPress cache plugin/drop-in support.
• Operational complexity.
• Memory behavior.
• Need for persistence or richer data structures.
• Monitoring and troubleshooting requirements.
• Hosting/platform support.

Last verified: September 25, 2026.

---

1. What Is the WordPress Object Cache?

The WordPress Object Cache stores data that would otherwise be expensive to regenerate, such as repeated database-query results.

By default, that cache exists only for the lifetime of the current request, as documented in the WordPress Object Cache reference.

Request starts
   ↓
WordPress creates object cache
   ↓
Queries / values cached in memory
   ↓
Request ends
   ↓
Default object cache disappears

A persistent object cache keeps suitable cached values available across requests.

WordPress also supports non-persistent cache groups, so not every value handled through the Object Cache API must be written to Redis or Memcached. Modern WordPress additionally exposes capabilities such as bulk operations, runtime flushing and group flushing; integrations should be checked with wp_cache_supports() rather than assuming every drop-in implements each feature safely.

---

2. Persistent Object Cache vs Full-Page Cache

They solve different problems.

For mostly public content, full-page caching may produce the larger gain because it can bypass much more application work than an object cache.

For logged-in, dynamic or database-heavy workloads, persistent object caching can become more relevant because PHP still runs and may repeatedly request reusable objects.

That does not mean dynamic WooCommerce pages should be put into a shared full-page cache. Cart, checkout, account and other personalized flows remain separate correctness problems; an object cache is an application-data optimization, not permission to cache personalized HTML globally.

---

3. Redis vs Memcached: Quick Comparison

---

4. Redis for WordPress

Redis is widely used as a persistent object-cache backend for WordPress.

Its strengths include:

• Broad WordPress integration support.
• Rich data structures beyond simple cache entries.
• Operational tooling and observability.
• Optional persistence features.
• Support across many managed hosting platforms.

For WordPress object caching, however, many of those capabilities may not be required.

Current Redis Object Cache integration example

The current WordPress.org Redis Object Cache 3.0.0 plugin supports Predis, PhpRedis and Relay clients plus replication, Sentinel, clustering and WP-CLI. A typical self-managed installation still requires both a reachable Redis service and an active wp-content/object-cache.php drop-in.

Useful non-secret checks include:

wp cache type
wp eval 'var_export( wp_using_ext_object_cache() );'
wp redis status   # only when the Redis Object Cache plugin provides this command

Do not publish connection passwords or complete diagnostics that expose secrets.

---

5. Memcached for WordPress

Memcached is designed around a simpler in-memory cache model.

Its strengths include:

• Simple cache-oriented architecture.
• Low operational complexity for straightforward caching.
• Long history in web application caching.
• Support through WordPress object-cache integrations.

Its simplicity can be an advantage when the only goal is ephemeral key/value caching.

Memcached WordPress integration needs extra verification

Memcached itself is current and actively maintained, but WordPress integration quality depends on the actual drop-in/plugin and PHP client. The WordPress.org directory contains several Memcached object-cache implementations with very different maintenance histories and tested WordPress versions.

Do not copy an old object-cache.php merely because a tutorial mentions Memcached. Verify:

• Which PHP client/extension the drop-in expects (Memcached vs legacy Memcache).
• Whether the integration supports your WordPress version and multisite model.
• Whether modern cache API features such as group flushing are implemented.
• Server list, key prefix/salt and failure behavior.
• Whether your managed host supplies its own tested Memcached integration.

---

6. Which One Is Faster?

Do not use a universal answer.

Performance depends on:

• Network path.
• PHP extension/client.
• Serialization.
• Object size.
• Concurrency.
• Hit rate.
• Eviction behavior.
• Server CPU and memory.

A benchmark that does not control those variables is not enough to declare a universal winner. Synthetic key/value throughput tests can describe the cache service under a specific test setup, but they do not automatically predict WordPress request performance. Vendor or third-party benchmark numbers should not be treated as representative of your site without matching test conditions.

---

7. Cache Hit Rate Matters More Than Brand Name

A persistent object cache is most useful when WordPress repeatedly requests objects that can be reused across requests.

If the hit rate is poor because the workload constantly generates unique or invalidated keys, changing from Redis to Memcached may not solve the real problem.

For service-level monitoring, treat hit rate as one signal rather than a target to maximize blindly:

hit_rate = hits / (hits + misses)

A high ratio can still hide stale-data bugs, oversized memory use or a workload where the cached operation was cheap. Pair hit/miss data with request latency, database work, evictions and correctness checks.

---

8. Object Cache Does Not Fix Slow PHP Code

If the application spends most of its time in:

• Slow PHP loops.
• External API calls.
• Image processing.
• Long-running plugin logic.

an object cache may have limited impact.

For broader backend diagnosis, use our TTFB Optimization Guide.

---

9. Object Cache Does Not Fix Worker Saturation

If all PHP workers are busy, new requests can still queue.

An object cache can shorten some requests, but it does not replace correct PHP worker sizing.

For that layer, use our PHP-FPM Tuning Guide.

---

10. Redis Persistence: Useful but Not the Same as Database Durability

Redis can be configured with persistence mechanisms, but WordPress object cache data should still be treated as disposable and regenerable.

Your database remains the source of truth.

Do not depend on the object cache as your only copy of business-critical data.

---

11. Memcached Is Intentionally Ephemeral

Memcached is designed as a cache, not a durable database.

If cached entries disappear after restart or eviction, the application should be able to rebuild them from the primary data store.

That model aligns well with the basic purpose of WordPress object caching.

---

12. Eviction and Memory Pressure

Both technologies operate under memory limits.

When memory fills, eviction behavior becomes important.

Monitor:

• Memory usage.
• Evictions.
• Hit/miss ratio.
• Connection count.
• Latency.

A cache that constantly evicts useful objects can provide little benefit.

Redis memory policy

Redis uses maxmemory plus maxmemory-policy to control behavior at the configured memory limit. Current Redis supports policies including noeviction, all-key LRU/LFU/random, volatile-key variants, and in Redis 8.6+ least-recently-modified policies such as allkeys-lrm and volatile-lrm. For a WordPress cache, the correct policy depends on the workload, whether cache entries consistently have TTLs, and whether write failures under noeviction are acceptable.

redis-cli INFO memory
redis-cli INFO stats
redis-cli CONFIG GET maxmemory
redis-cli CONFIG GET maxmemory-policy

Do not copy an eviction policy blindly from another site. If the Redis instance stores both cache data and application state, consider separating those workloads rather than treating every key as disposable.

Memcached memory and eviction

Memcached organizes items into slab classes and can evict still-valid items from an LRU when the relevant slab class cannot allocate space. Its documentation recommends watching overall/per-slab hit behavior and eviction statistics rather than treating one global memory number as sufficient.

printf 'stats\r\n' | nc 127.0.0.1 11211
printf 'stats settings\r\n' | nc 127.0.0.1 11211
printf 'stats items\r\n' | nc 127.0.0.1 11211
printf 'stats slabs\r\n' | nc 127.0.0.1 11211

Run these only from an authorized host. Do not expose the Memcached service publicly just to make monitoring easier.

---

13. WooCommerce Workloads

WooCommerce has more dynamic and personalized traffic than a simple brochure site.

Persistent object caching can help only where WooCommerce, WordPress or plugins actually reuse cacheable objects—for example repeated product, taxonomy, option or query-derived data. The benefit must be measured on the store's request mix.

Do not infer from that that cart, session or order state can be cached arbitrarily. Correctness checks must cover:

• Different shoppers seeing different carts.
• Coupon and total recalculation.
• Inventory/stock changes.
• Checkout address/shipping/tax updates.
• Logged-in account data.
• Order creation and payment/webhook state.

If stale object-cache data causes any of these flows to return incorrect state, the cache configuration or integration is not production-safe regardless of its hit rate.

If the main question is which hosting environment fits an ecommerce workload, use our Best Hosting for WooCommerce guide.

---

14. WordPress Hosting Support Matters

Many managed WordPress hosts already provide or manage a persistent object cache.

Before installing your own Redis or Memcached service, check:

• Whether object caching is already enabled.
• Which backend the host supports.
• Whether a specific plugin/drop-in is required.
• Whether self-managed services are allowed.

If you want provider selection rather than server-level cache operations, use our Best WordPress Hosting guide.

---

15. Redis Licensing in 2026

Redis licensing changed across recent major releases, so check the version you actually deploy.

Current Redis licensing documentation states:

• Redis 7.2 and earlier: BSD-3-Clause.
• Redis Community Edition 7.4–7.8: RSALv2 or SSPLv1.
• Redis Open Source 8+: RSALv2, SSPLv1, or AGPLv3.

Redis describes AGPLv3 as the OSI-approved open-source option in the Redis 8+ tri-license. RSALv2 and SSPLv1 are source-available licenses and are not OSI-approved open-source licenses.

For a normal WordPress deployment, licensing is separate from cache performance. Organizations that redistribute Redis, modify it, or provide Redis functionality as a managed service should review the current terms for the exact version and deployment model.

---

16. Security: Do Not Expose Redis or Memcached Publicly

Object-cache services should normally be reachable only by trusted application hosts. Binding to localhost or a private network and applying firewall controls are common baseline protections, but exact security options depend on the backend and deployment model.

Do not expose default service ports directly to the public internet.

Redis provides ACL, authentication and TLS options depending on deployment, and Memcached can be built/configured with SASL support in some environments, but network isolation remains the baseline. Authentication is not a reason to expose either cache directly to arbitrary internet clients.

Use:

• Localhost or private-network binding.
• Firewall rules.
• Authentication where supported and appropriate.
• Network segmentation.

---

17. Redis Example: Localhost Binding Concept

A typical security objective is:

WordPress / PHP
      ↓
localhost/private network
      ↓
Redis

Public internet
      ✕
Direct Redis access

---

18. Memcached Example: Private Access Concept

The same principle applies:

Application server
      ↓
private/local connection
      ↓
Memcached

---

19. How to Check Whether WordPress Has a Persistent Object Cache

Useful checks include:

• Hosting control panel.
• Plugin/drop-in status.
• Presence of wp-content/object-cache.php.
• WordPress Site Health, where the installed stack reports persistent object-cache status.
• WP-CLI cache commands.

Do not assume WP_CACHE alone means persistent object caching is active.

Cross-process persistence probe

A useful test is to set a uniquely named key in one WP-CLI process and fetch it from a second process:

GROUP="digitalbhatti_probe"
KEY="probe_$(date +%s)"
VALUE="persistent-ok"

wp cache set "$KEY" "$VALUE" "$GROUP" 300
wp cache get "$KEY" "$GROUP"
wp cache delete "$KEY" "$GROUP"

If the second process cannot read the value, investigate the drop-in/backend rather than assuming persistent caching is enabled. Run the test on the intended site URL/context in Multisite.

---

20. WP-CLI Cache Commands

WP-CLI exposes commands for interacting with the WordPress object cache.

wp cache type
wp cache supports flush_group
wp cache supports get_multiple
wp cache get my_key my_group
wp cache set my_key my_value my_group 300
wp cache delete my_key my_group

Avoid using wp cache flush as a routine validation step. WP-CLI warns that on WordPress Multisite with a persistent object cache a full flush will typically flush the cache for all sites, which can cause a regeneration spike.

Before using group flushing programmatically, WordPress specifically instructs developers to check wp_cache_supports( 'flush_group' ). Modern core polyfills cache functions, so checking only function_exists() does not prove the active backend really supports the feature.

---

21. Cache Stampede Risk

When many requests simultaneously miss the same expensive cache entry, they may all try to regenerate it.

This is sometimes called a cache stampede or thundering-herd problem.

The correct mitigation depends on the application/plugin and cannot be solved merely by choosing Redis over Memcached.

---

22. Multisite Considerations

WordPress Multisite can place more diverse key groups and workloads into the persistent cache.

Verify:

• Plugin/drop-in compatibility.
• Network/site-specific key-prefix behavior.
• Which groups are global across the network.
• Whether a full flush affects every site.
• Memory growth and eviction behavior.

Use wp --url=site-a.example ... and wp --url=site-b.example ... with unique test keys to confirm site-specific data cannot collide unexpectedly. Do not assume changing Redis database numbers is the only or correct isolation strategy; follow the integration's documented key-prefix/global-group model.

---

23. When Redis Is Usually the Easier Choice

Redis is often a practical choice when:

• Your host already supports it.
• Your WordPress stack has a well-supported Redis drop-in.
• You want stronger tooling/observability.
• You already operate Redis for other application needs.

---

24. When Memcached Is Usually the Easier Choice

Memcached can be attractive when:

• You need only a straightforward ephemeral object cache.
• Your hosting stack already supports it.
• You prefer a simpler cache-focused service.
• Your application integration is already proven.

---

25. Do Not Change Backends Without a Reason

If a production WordPress site already has:

• Good hit rate.
• Low eviction pressure.
• Stable memory usage.
• Acceptable backend latency.

switching from Memcached to Redis—or the reverse—may add risk without a measurable benefit.

---

26. When Neither Redis nor Memcached Is the First Fix

A persistent object cache may be the wrong first optimization when the main bottleneck is elsewhere.

Do not deploy or switch object-cache backends merely because Redis or Memcached appears on an optimization checklist. First investigate whether the site is limited by:

• uncached full-page generation that could be handled by page caching;
• slow third-party API calls;
• PHP worker saturation;
• slow plugin/theme code;
• database queries that are unique or constantly invalidated;
• large frontend assets or render-blocking resources;
• insufficient CPU, memory or database capacity.

If repeated cacheable object/database work is not a meaningful part of request time, adding Redis or Memcached may increase operational complexity without producing a useful improvement.

---

27. Validate Cache Correctness Before Benchmarking Speed

A persistent cache that returns stale or cross-user data is a failed configuration even if it reduces database queries.

Perform failure testing on staging or a controlled maintenance window. Do not stop a managed provider's cache service or flush a production network merely to complete a checklist.

---

28. How to Benchmark Redis vs Memcached Fairly

If you want to compare Redis and Memcached on your own WordPress site, use a reproducible methodology and keep the following variables constant:

• Same server resources.
• Same WordPress version.
• Same plugin/theme stack.
• Same WordPress Object Cache API behavior and equivalent integration settings; document when Redis/Memcached require different drop-ins/clients.
• Same PHP version and client extension/library versions.
• Same serialization/compression settings where comparable.
• Same Redis/Memcached network path: local socket, TCP or private network.
• Same cache warm-up process.
• Same request set.
• Same concurrency.
• Same test location.

Track:

• TTFB.
• Database query time/count.
• Cache hit rate.
• Evictions.
• Memory usage.
• Median, p95 and p99 request latency.
• Throughput and HTTP error rate.
• PHP/database CPU and memory.
• Cache-service CPU and memory.
• Backend latency/connection errors.

Do not publish a winner from one request or a cache-service microbenchmark. Document server hardware, OS, WordPress/PHP/database versions, Redis/Memcached versions, PHP client/drop-in, serialization, memory limits/eviction policy, warm-up procedure, request mix, concurrency, test location, sample size and raw measurements.

Run both anonymous cacheable and dynamic/logged-in application workloads where relevant. If a full-page cache serves the anonymous request before WordPress runs, that request is measuring the page cache rather than Redis vs Memcached object caching.

For production changes, define a rollback plan before switching backends: record the existing plugin/drop-in, service configuration, connection settings and cache state so you can restore the previous working configuration if errors or latency regressions appear.

Results worksheet — not yet a Digital Bhatti benchmark

Leave the table blank until the same WordPress workload has actually been tested on a Digital Bhatti-controlled environment. A smaller synthetic GET/SET latency number is not automatically a faster WordPress request.

---

29. Redis vs Memcached Decision Matrix

---

30. Final Decision Framework

There is no universal Redis-vs-Memcached winner for WordPress.

A practical decision sequence is:

Check what your host / stack supports
        ↓
Confirm maintained drop-in + PHP client compatibility
        ↓
Verify persistent cache across separate requests/processes
        ↓
Test invalidation / key isolation / backend failure behavior
        ↓
Measure hit/miss/evictions + application DB/request latency
        ↓
Identify whether object caching is actually a bottleneck
        ↓
Benchmark equivalent Redis/Memcached workloads if a switch is justified
        ↓
Keep or switch based on correctness + measured evidence + operations

Redis can fit well when its integrations, tooling or broader data-store capabilities are useful. Memcached can fit well when a simple ephemeral cache is all the application needs. The correct choice is the one that your WordPress stack supports reliably and that performs well under your measured workload.

---

Frequently Asked Questions

Does WordPress have object caching by default?

Yes, but the built-in object cache is non-persistent by default and lasts only for the current request unless a persistent cache backend/drop-in is installed.

Is Redis better than Memcached for WordPress?

Not universally. Redis is widely supported and offers richer functionality, while Memcached provides a simpler cache-focused model. Use the option that fits your stack and measured workload.

Does Redis replace page caching?

No. Redis object caching and full-page caching solve different problems.

Can Redis improve TTFB?

It can when repeated database/object work is a meaningful part of backend latency and cache hit rates are good. It does not guarantee a specific TTFB.

Can Memcached improve WooCommerce performance?

It can reduce repeated object/database work for suitable workloads, but the actual benefit depends on cache usage, queries, invalidation and application behavior.

Should Redis or Memcached be publicly accessible?

No. They should normally be limited to trusted application hosts or private/local networking.

Does defining WP_CACHE enable Redis?

No. Current WordPress documentation says persistent object caching uses an object-cache.php drop-in, and persistent caching may function even when WP_CACHE is not defined. The constant alone does not enable Redis or Memcached.

Did Redis licensing change?

Yes. Redis 8+ is currently available under RSALv2, SSPLv1 or AGPLv3, with AGPLv3 providing an OSI-approved open-source option.

What Redis and Memcached versions were current for this update?

This article was verified on September 25, 2026 against Redis Open Source 8.10.2 and Memcached 1.6.45. Distribution packages can lag upstream, so record the installed version rather than assuming the latest release.

Which Redis WordPress plugin was verified?

The WordPress.org Redis Object Cache plugin was at 3.0.0, tested through WordPress 7.1.2. Managed hosts may use a different drop-in or commercial integration, so verify what actually owns wp-content/object-cache.php.

How can I verify persistent object caching without flushing the site?

Use wp cache type, wp_using_ext_object_cache(), inspect the active drop-in, then set/get/delete a uniquely named test key across separate WP-CLI processes. That verifies persistence without requiring a site-wide flush.

Can wp cache flush affect every site in WordPress Multisite?

Yes. WP-CLI warns that with a persistent object cache, a full flush on Multisite will typically flush the cache for all sites. Use targeted operations and confirm feature support before flushing groups.

Does a high cache hit rate prove the configuration is good?

No. A cache can have a high hit rate while serving stale data or consuming excessive memory. Evaluate invalidation correctness, request/database latency, evictions, backend errors and dynamic application behavior as well.