Compatibility and Integrations
Scalability Pro sits underneath everything else on your site and speeds up the raw SQL that WordPress and your plugins run. Because it works at the database and query layer rather than replacing any part of your stack, it is designed to coexist with the plugins and hosting you already use. It adds its own database indexes, caches a handful of expensive counts, and rewrites specific slow queries as they run. Nothing it does changes your content, and most of it is reversible by turning an option off or dropping the indexes.
This article covers what Scalability Pro works well alongside, the plugins it has specific optimisations for, and how it fits with your caching and object-cache layers.
Works alongside your page cache
Scalability Pro is not a caching plugin and does not replace one. It speeds up the uncached work: generating a page the first time so it can be stored in your cache, and everything that never gets cached at all, such as wp-admin, imports, cron, logged-in sessions and REST requests. That makes it complementary to any page-caching plugin. You do not need a particular one; any page cache will do, and Scalability Pro runs happily behind it.
In practice our customers run it alongside WP Rocket, LiteSpeed, W3 Total Cache, Cloudflare and Perfmatters with no conflict. If your host offers server-level (FastCGI) page caching, prefer that over a page-cache plugin. Two practical notes: avoid a page cache “preload” or “prime” feature that loads every page at once, and note that a fast page cache still leaves your admin and imports slow, which is exactly the gap Scalability Pro fills.
A page cache only ever speeds up the second visitor to a page. The first visitor, every logged-in session, every wp-admin screen, every import and every cron run all hit the database live. That uncached slice is precisely what Scalability Pro accelerates, which is why the two layers add up rather than overlap.
Object cache and Redis
An object cache is strongly recommended alongside Scalability Pro because the two do different jobs: the object cache remembers the result of repeated lookups, while Scalability Pro makes the underlying queries fast in the first place. Redis (via the Redis Object Cache plugin) or Memcached are the usual choices, with Docket Cache as a file-based fallback.
Scalability Pro does not ship its own Redis or object-cache backend, and it does not require one. It uses its own file-based and table-based cache internally for the counts it stores, and it treats a Redis or Memcached object cache as complementary infrastructure that you install separately. Its database indexes are ordinary MySQL indexes and have nothing to do with your object cache, so flushing Redis never affects them.
Run a persistent object cache (Redis or Memcached) alongside Scalability Pro. The object cache remembers repeated lookups, Scalability Pro makes the underlying query fast the first time, and together they push a typical page’s query count down towards the single figures.
Plugins we optimise specifically
- WooCommerce. This is the largest area of work. Scalability Pro adds the indexes WooCommerce needs at scale, caches the per-status post counts that slow the admin order and product screens, and includes targeted rewrites for specific WooCommerce queries. It is fully compatible with WooCommerce HPOS (High-Performance Order Storage) and WooCommerce Subscriptions. See WooCommerce Admin Query Fixes, Optimise WooCommerce Updates, Cache WooCommerce Shortcodes and Optimise Product Attributes Lookup.
- WP All Import. Large imports are one of the most common reasons people install Scalability Pro. It adds several indexes that WP All Import relies on for its SKU, GUID and duplicate-check lookups, works with the Defer Term Counting and Cache Post Counts options to stop per-row recounts during a run, and provides a diagnostic parameter so you can watch an import batch render in the browser with Query Monitor. See Diagnosing WP All Import Performance Issues with Scalability Pro.
- WP All Export. Editing an export triggers a
SELECT DISTINCT meta_keyscan across the wholewp_postmetatable, which crawls on a large store. There is a dedicated option to avoid that enumeration. See Avoid Expensive WP All Export meta_key Enumeration.
- Datafeedr. Datafeedr is named in the plugin description as one of the tools Scalability Pro helps, and Datafeedr-driven affiliate stores benefit from the same import and query optimisations as any other large catalogue: the indexes, deferred term counting, reduced image sizes and the general
WP_Queryspeed-ups. Note that this is generic import-path optimisation. There is no Datafeedr-specific code path in the plugin, so treat Datafeedr as covered by the general WooCommerce and import optimisations rather than as a bespoke integration.
- Action Scheduler. Action Scheduler is the background job system used by WooCommerce, WooCommerce Subscriptions and many import plugins. Its tables grow into the millions of rows on a busy store and slow the whole site. The Optimize Action Scheduler option shortens retention so old actions are cleared sooner, with buttons to empty the tables and clear the logs. See Optimise Action Scheduler.
- Large custom post type sites. Scalability Pro is not WooCommerce-only. It speeds up
WP_Queryfor any post type, so blog archives, custom post types, forums, directories and listings sites all benefit from the indexes and query rewrites. For dramatically faster author, taxonomy and filtered archive queries at scale there is a separate add-on. See Super Speedy Archives Add-on.
Some behaviours are opt-in and gated behind constants you set in wp-config.php. The nav menu optimisations (SPRO_NAV_MENU_OPTIMISATIONS) and the nav-menu-items query filters (SPRO_ALLOW_NAV_MENU_ITEMS_FILTERS) both default to off, for example, so they only apply if you deliberately enable them.
Hosting, WordPress, PHP and database
Scalability Pro requires WordPress 6.4 or newer and PHP 7.0 or newer. The supported database floor is MySQL 5.7 or MariaDB 10.2 with InnoDB DYNAMIC row format, which can build the plugin’s full-length utf8mb4 meta_key index. MySQL 8.0.1 or MariaDB 10.8 and newer also preserve the descending direction declared by five date indexes; older supported releases build those keys in ascending order.
It works on multisite and with a non-standard database table prefix. It runs on standard control-panel and managed hosting; the counts and indexes it manages live in your own database.
General compatibility
Most of what Scalability Pro does is inherently safe. Adding a database index cannot change your results; it only gives MySQL a faster path to the same rows. The indexes have their own distinct names and never touch a core WordPress index, so they will not clash with WordPress updates. Caching counts does not change your content either. These are the parts you can leave on and forget about.
A smaller set of options deliberately change query behaviour, and those are the ones to be deliberate about. Removing SQL_CALC_FOUND_ROWS changes how totals are reported, and rewriting main-query joins changes how a query resolves. They are off by default and opt-in for that reason. When you need one of these on only around a specific hook or page rather than site-wide, use the targeted approach in Custom Query Alterations instead of the blanket option.
One plugin to avoid running alongside it is “Index WP MySQL for Speed”, which deletes Scalability Pro’s indexes and alters core primary keys. Do not run both.
Running “Index WP MySQL for Speed” at the same time as Scalability Pro. It removes Scalability Pro’s indexes and changes core primary keys, so the two fight each other. Pick one indexing tool, not both.
When to check with support
If you run an unusual multilingual, filter or search plugin, or something that reads directly from wp_posts in ways WordPress does not expect, and you are not sure whether a particular query-altering option is safe with it, ask us on Discord before enabling it on a live site. Test the query-altering options on staging first, keep the safe index and caching options on, and reach out with a Query Monitor screenshot (ordered by row count) if a specific query stays slow.
Comments