Redis Object Cache for Membership Sites: When It Helps and When to Leave It Off
Should a membership site run Redis object caching? LearnDash, BuddyBoss and LifterLMS support it, MemberPress lists it as a problem. What each plugin's own docs say, and how to test it safely.
Redis object caching can cut repeated database work on logged-in pages, because WordPress and its plugins can reuse data it keeps in memory instead of asking MySQL again on every request. Whether you should switch it on depends on which plugins run your site. LearnDash, BuddyBoss and LifterLMS all document support for object caching. MemberPress lists the Redis Object Cache plugin among its known incompatibilities and says to disable object caching.
Check your plugins first. If none of them warns against it, test it on a staging copy with the flows that make you money (sign-up, login, renewal, access rules, course progress) before it goes anywhere near production.
Sources below are each vendor’s own documentation, checked on 19 September 2026. Citing a company’s documentation doesn’t mean it endorses this article, and product names are trademarks of their owners.
What the WordPress object cache does, and what Redis adds
WordPress already has an object cache. It just forgets everything at the end of each request. From WordPress’s developer reference: “By default, the object cache is non-persistent. This means that data stored in the cache resides in memory only and only for the duration of the request. Cached data will not be stored persistently across page loads unless you install a persistent caching plugin” (WordPress).
A persistent backend such as Redis keeps that data between requests. When a member loads their dashboard, WordPress can pull their user data, options and query results from memory instead of rebuilding them from the database.
On a membership site, the page cache sits out most of what members do: their dashboards, lessons and account pages are built for them alone, so WordPress assembles each one in PHP, usually with database queries. An object cache doesn’t avoid PHP, but it can cut the number of database queries each request makes. BuddyBoss measured an average 35% reduction in database requests with Redis object caching on its own test site (BuddyBoss).
What each membership plugin says about object caching
This is where most Redis guides stop being useful for membership sites. The plugin vendors disagree, and each one’s documentation is the thing to follow for your site.
| Plugin | What its own docs say | Source |
|---|---|---|
| MemberPress | Lists Redis Object Cache as causing “various problems with MemberPress functionality, due to object caching” and gives the solution “Disable object caching” | MemberPress |
| LearnDash | Has a LEARNDASH_OBJECT_CACHE_ENABLED constant for object cache support, on by default | LearnDash |
| BuddyBoss | Recommends “Redis Object Cache: Install and enable Redis for faster database lookups” | BuddyBoss |
| LifterLMS | ”LifterLMS fully supports persistent object caching solutions, such as Redis and Memcached” | LifterLMS |
| Paid Memberships Pro | Object caching is set up for the whole site, not by the plugin; after changing restriction settings “you may need to manually clear the object cache” | Paid Memberships Pro |
MemberPress
MemberPress is the outlier, and it is specific about why. Besides the incompatibility listing, its guide to hosting says “issues most often come from object caching and Varnish cache. These should be disabled so MemberPress can work properly” (MemberPress). Its troubleshooting page for disappearing user accounts names object caching as one cause: “Site owner or Web-host has Database/Object caching enabled, causing some accounts to get overridden by POST data from a new signup (Most common on WP Engine or GoDaddy). This is extremely difficult to reproduce, but disabling the database/object caching fixes it” (MemberPress).
A bug that overwrites member accounts and is hard to reproduce is exactly the kind you don’t want to discover in production. If MemberPress runs your site, the default is off. A clean test on staging doesn’t prove the problem away either: MemberPress itself calls it “extremely difficult to reproduce” (MemberPress). Treat any exception as a decision for someone who can investigate your exact setup, with MemberPress’s warning in front of them.
LearnDash, BuddyBoss and LifterLMS
These three lean the other way. LearnDash switches its object cache support on by default (LearnDash), so it will use a persistent cache if your site has one; the Redis side still has to be set up separately. BuddyBoss’s hosting guide recommends a stack of “Redis Cache”, “Relay” and “Object Cache Pro” (BuddyBoss), and its own benchmark ran with Redis on.
Support doesn’t mean nothing can go wrong. LifterLMS documents a specific failure: “If a newly registered student receives an ‘Invalid username or password’ error immediately after checkout, or if their new user session is not recognized, this is caused by a stale user/session query in an object cache or database cache.” Its advice starts with flushing the object cache, then checking how user data is cleared from the cache, any database caching add-ons, and that checkout is excluded from caching (LifterLMS). Worth knowing before a launch, when new students arrive in a rush.
Paid Memberships Pro
PMPro treats object caching as a site-level decision. Its warning is about stale access rules: “if you change level restrictions for a post or update the category restrictions for a level, or make many other restriction settings, you may need to manually clear the object cache to make sure your site functions as intended” (Paid Memberships Pro). After changing restrictions, check that the new rules actually apply, and flush the cache if they don’t.
Sites with more than one of these
Plenty of sites run LearnDash with MemberPress, or BuddyBoss with a membership plugin. The most cautious plugin on the site sets the rule. A LearnDash course sold through MemberPress is a MemberPress site as far as object caching goes.
Redis Object Cache, Object Cache Pro and Relay
Three names come up whenever Redis and WordPress are mentioned together. They do different jobs:
- Redis Object Cache is the free plugin on WordPress.org: “A persistent object cache backend powered by Redis” (WordPress.org). It’s the one MemberPress’s incompatibility list names.
- Object Cache Pro is a paid plugin, promoted on the free plugin’s WordPress.org page and described by its makers as “A business class Redis object cache backend” (Object Cache Pro).
- Relay is a PHP extension rather than a WordPress plugin. It “keeps a partial, in-memory replica of your Redis data inside PHP’s shared memory pool” (Object Cache Pro docs), so frequent reads skip the network trip to Redis.
All three need a Redis server your site can reach (Relay also needs its PHP extension installed), so ask your host whether your plan supports them. Swapping the free plugin for Object Cache Pro doesn’t settle the MemberPress question: MemberPress’s advice is “Disable object caching” (MemberPress), not a particular plugin.
When object caching is worth it, and when it isn’t
It tends to pay off when:
- Most of your traffic is logged in, so the page cache can’t help much.
- Your own measurements show heavy database work on member pages. Query Monitor reports one page load at a time, so note the query count, query time and page generation time for the same pages before and after, and compare.
- Your plugins document support for it, as LearnDash, BuddyBoss and LifterLMS do.
It’s less useful, or risky, when:
- Your main plugin warns against it, as MemberPress does.
- Your measurements show little repeated database work, or little improvement once it’s on. Then you’ve added a moving part that can serve stale data for not much gain.
- Nobody is set up to flush it when access rules change or when members report stale data.
How to lower the risk when you test it
- Copy the site to staging with the same plugins, and make it safe: payment gateways in test or sandbox mode, customer emails switched off, and a Redis database (or Redis server) of its own, plus its own key prefix, so staging never shares cache with the live site. A flush clears the whole Redis database it points at, so a shared database with different prefixes isn’t enough. MemberPress has a staging guide for the gateway side.
- Measure first. Load your slowest logged-in pages with Query Monitor and note the query count and total time.
- Enable the object cache on staging only and confirm it is connected. The plugin’s status screen or Query Monitor will show whether a persistent cache is in use.
- Run the money flows with test accounts and sandbox payments. A new sign-up, a login straight after checkout, a renewal, an upgrade and a downgrade, a change to a level’s access rules, and a lesson marked complete. Log in as two different test members and check each sees only their own content.
- Measure again, then decide. If the flows pass and the logged-in pages got faster, apply the tested caching settings on the live site at a quiet time, keeping the live site’s own Redis database and prefix (never staging’s), confirm the live cache is separate, and watch the next few days of sign-ups closely. Don’t copy the staging database over live.
How we handle it
We configure caching per site. On MemberPress sites we test object caching on a copy before it goes anywhere near the live site, and we leave it off when the plugins disagree with it, which with MemberPress’s current guidance is the default. That’s also why we don’t promise Redis on every plan. More on how we set up hosting for each plugin is on our MemberPress, LearnDash and BuddyBoss pages, and our performance page covers the rest of the stack.
Frequently Asked Questions
Does Redis work with MemberPress?
MemberPress lists the Redis Object Cache plugin as causing “various problems with MemberPress functionality” and recommends disabling object caching (MemberPress). Its docs also link object caching to user accounts being overwritten by a new sign-up, a problem it calls hard to reproduce. Leave it off. Passing tests on staging doesn’t show that the problem can’t happen on your site.
Is Redis object caching good for LearnDash?
LearnDash enables its object cache support by default through its LEARNDASH_OBJECT_CACHE_ENABLED constant, and uses a persistent cache such as Redis when your site has one set up (LearnDash). If LearnDash is sold through MemberPress on the same site, follow MemberPress’s guidance instead.
What is the difference between page caching and object caching?
A page cache stores the finished HTML of a page. Personal member pages usually have to bypass a shared page cache, unless the caching setup keeps each member’s version separate. An object cache stores pieces of data, such as query results and user data, that PHP uses to build a page, so it can help pages the page cache can’t serve.
Do I need Object Cache Pro, or is the free Redis plugin enough?
For many sites the free Redis Object Cache plugin is enough to see whether object caching helps. Object Cache Pro is a paid plugin that its makers describe as a “business class” backend. Neither changes the plugin compatibility question, so test either one against your membership plugin first.
How do I clear the object cache?
Use the flush control in your object cache plugin, or WP-CLI’s wp cache flush. Check with your host what a flush covers first: on multisite or a shared Redis, it can clear more than one site’s cache. Paid Memberships Pro notes that after changing restriction settings “you may need to manually clear the object cache” (Paid Memberships Pro), so check new rules take effect.