Frequently Asked Questions

The questions we’re asked most often about Scalability Pro, drawn from five years of support. For problems and error messages, see the Troubleshooting guide, or ask us on Discord.

Is Scalability Pro safe, and can I reverse it?

Yes, everything it does is reversible. It doesn’t change any of your data (the one exception is category/term counts if you use the Defer term counting option, and those can be recounted). It creates database indexes when you create them, and it alters queries as they run – turn an option off and it stops doing it. To uninstall cleanly, go to the Indexes tab, delete the indexes, then deactivate the plugin, and your site is exactly as it was before. Note that indexes are deleted automatically when you deactivate, so if you ever deactivate and reactivate you’ll need to recreate them (Select All > Update Indexes).

Does it help non-WooCommerce sites and custom post types?

Yes. Scalability Pro speeds up WP_Query for any post type – blog archives, custom post types, forums (bbPress), directory and listings sites – as well as wp-admin. It adds the missing indexes and rewrites queries to use them. Most large sites that need it happen to be WooCommerce stores, but it isn’t WooCommerce-only. It won’t speed up search (that’s Super Speedy Search) or badly-coded filter plugins.

How do I know if it will help my site?

A quick check: look at the number of rows in your wp_postmeta table. Once it’s above roughly 5,000-10,000 rows you’ll usually see a noticeable benefit, and wp_postmeta grows large even on sites with a modest number of posts. More generally, install the free Query Monitor plugin and look at your slowest pages – if you see slow queries reported, Scalability Pro will help; if instead you see thousands of queries, you probably need Super Speedy Filters or Super Speedy Search too. Scalability Pro won’t speed up tiny sites, but it stops a growing site from slowing down. There’s a 60-day money-back guarantee.

Do I need Redis or an object cache, and how do I set it up?

An object cache is strongly recommended alongside Scalability Pro (they do different jobs). Redis is best – install it on your server (it’s free, your host can enable it) and use the Redis Object Cache plugin by Till Kruss. If you can’t get Redis, Memcached is a good alternative, and if you can’t get either, the free Docket Cache plugin works well. Avoid LiteSpeed’s built-in object cache and managed/remote Redis – a page can make thousands of object-cache calls, so any network latency between WordPress and Redis destroys the benefit. Configure Redis to stay in memory: comment out the three save lines in redis.conf (put a # in front), and set a memory limit and eviction policy, otherwise Redis will eventually eat all your RAM:

maxmemory 3000mb
maxmemory-policy allkeys-lfu

Is it compatible with WP Rocket, LiteSpeed, Cloudflare, HPOS, Subscriptions and multisite?

Yes to all of these. Scalability Pro isn’t a caching plugin – it speeds up the raw SQL – so it runs happily alongside WP Rocket, LiteSpeed, W3 Total Cache, Cloudflare, Perfmatters and a Redis object cache. Two tips: prefer server-level page caching over a page-cache plugin if you have it, and don’t turn on WP Rocket’s cache “preload”/prime option (it loads all your pages at once). It’s fully compatible with WooCommerce HPOS (High-Performance Order Storage) and WooCommerce Subscriptions, works on multisite, and works with a non-standard database table prefix with no changes.

Should I also run “Index WP MySQL for Speed”?

No. Running its “update indexes” deletes all of Scalability Pro’s indexes, and it modifies core primary keys (for example turning the wp_postmeta primary key into a unique key, which effectively drops the meta_key index). Scalability Pro deliberately leaves core indexes untouched and only adds its own, so it’s safer and fully reversible. If you run both, the last one to create indexes wins, and you’ll have to recreate Scalability Pro’s afterwards.

Do the indexes auto-update, or conflict with WordPress core and updates?

The indexes are ordinary MySQL indexes, maintained automatically by MySQL – they’re always up to date as your posts change and never need manual rebuilding. They’ve got nothing to do with Redis, so flushing your object cache doesn’t affect them. They also have their own distinct names and don’t alter any existing core index, specifically so they can’t break WordPress updates the way index plugins that change a core table’s key can. They even remain in place if you deactivate the plugin, so if you want a clean before/after speed test, delete them first.

Which multilingual plugin should I use?

Avoid WPML – it’s some of the worst-performing SQL we’ve seen (correlated aggregated subqueries that can’t use an index, so it reads huge numbers of rows), and Scalability Pro can’t optimise it. Use Polylang or TranslatePress instead; both are well coded and scale. If you only need the interface text translated rather than your content, Loco Translate uses the built-in .po/.mo files and is fastest of all.

Which filter and search plugins don’t scale?

Most WooCommerce filter and search plugins aren’t built for scale – they fetch thousands of rows and process them in PHP, which shows up as high PHP time and low SQL time in Query Monitor. Ones we repeatedly see struggle include FacetWP, Search & Filter Pro, JetSmartFilters and WOOF, along with the default WooCommerce Price Filter. Scalability Pro can’t rewrite them from inside a separate plugin. The two options for fast filters are our Super Speedy Filters plugin or ElasticPress.

How do I recount category/term counts from the command line?

The standard WP-CLI recount is:

wp taxonomy list --field=name | xargs wp term recount

If Defer term counting is switched on, the standard recount may not take effect – use Scalability Pro’s own function instead: wp eval 'spro_recount_items();'. In a post-processing script you can also call wp_defer_term_counting( false ); then spro_recount_items();. See the Troubleshooting guide for the root-owner/Plesk variants.

What’s the difference between Defer Term Counting and Cache Post Counts?

They deal with two different kinds of count. Post counts are the per-status totals, for example how many orders are pending, processing or complete (Scalability Pro caches these in its wp_scalability_pro_post_count_cache table). Term counts are how many items are in a given category, tag or attribute term. They use different mechanisms, so they’re not interchangeable – Cache Post Counts speeds up the admin status filters and imports, while Defer term counting stops the per-row category recount during bulk changes.

How do I get the fastest WP All Import imports?

First, make sure all the indexes are built and every option on the Imports tab is enabled. Beyond that, most of the ceiling is WP All Import’s own architecture – it processes one item at a time in PHP with the full WordPress environment loaded per row, so Scalability Pro typically makes imports 3-10x faster but can’t remove that per-row cost. Practical tips from our customers:

• Split large files and run several imports at once – WP All Import uses only one CPU core per import, so parallel imports use the rest of your cores.
• Create a separate, stripped-down “update” import that only touches price and stock, and run that daily, with the full import weekly.
• Set up a real server cron (every minute or 5 minutes) rather than relying on WP-cron.
• If you use Super Speedy Filters, enable its “Remove Woo Baggage” option to stop the Action Scheduler attribute-lookup jobs piling up during imports.

How do I debug slow imports when they run over ajax?

WP All Import (and product/order edits) run over ajax, so Query Monitor and code profilers can’t normally see them. Scalability Pro lets you run a single import batch through a normal wp-admin page instead: append &spro_show_import_queries=1 to your wp-admin URL (not wp-load.php – that won’t load Query Monitor). Load the import’s “trigger” URL once, then load the “processing” URL parameters after /wp-admin/ with &spro_show_import_queries=1 added, and you’ll see the page render with Query Monitor’s results, so you can find the slow queries and which plugin they come from. There’s a full walkthrough in Using the Slow Query Log and the WP All Import debugging article.

Why does pagination stop working when Scalability Pro is enabled?

One of the options in Scalability Pro is to remove SQL_CALC_FOUND_ROWS, which is there because on very large sites (over 100,000 products) the archive becomes slow purely from MySQL counting how many products and pages there are. With that option on, pagination still works, but Scalability Pro fakes the total (it doesn’t calculate the real number of pages). So if you use it, either hide the page counts, replace the final page number with a word like “Many” (there’s an option for that), or use an infinite scroll plugin. You can change the faked total with the spro_num_pages filter if you need a specific number.

Does Scalability Pro speed up WooCommerce product variations?

Not directly. Scalability Pro speeds up slow SQL that runs through WP_Query, and it reduces the overall load on your server (which leaves more headroom for variations), but the core problem with variations is a PHP one: if you have 4 dropdowns of 10 options each, that’s 10,000 variations, and WooCommerce loads all of them into RAM on the product page and on archive pages. The best approach is to reduce how many variations you have – a variation should really change the image; if it only changes the price by a fixed amount it can be a product option or add-on instead – then put a Redis object cache in front. In some cases Scalability Pro does help directly, if a plugin or theme runs slow SQL when a variation is fetched.

Why am I seeing a wp_options performance warning, and how do I fix it?

WordPress loads every option with autoload = 'yes' into memory on every page load, so if a plugin has put hundreds or thousands of rows in there, it burns PHP CPU time on every request (you’ll see low SQL time but high overall page-generation time in Query Monitor). To fix it: install a Redis object cache so your transients move out of wp_options, then clean up the old transients that are still in the table:

delete from wp_options where autoload = 'yes' and option_name like '_transient%';

If the warning persists, find which plugin is responsible by grouping the autoloaded options:

select left(option_name,15) option_name, count( * ) total
from wp_options where autoload = 'yes'
group by left(option_name,15)
order by total desc
limit 20;

Each plugin prefixes its option names, so the top rows tell you the culprit – then you can delete those options or switch them to autoload = 'no' (set autoload to any non-yes value so you can revert). Do this cleanup before enabling Redis. To run SQL, use a desktop client over SSH such as Beekeeper Studio or TablePlus rather than exposing your database through wp-admin.

How do I copy my settings between sites?

Use the Advanced tab. Export your Scalability Pro settings to a file (copy to clipboard or download as JSON), then paste them into the Import panel on another site. Importing overwrites all current settings, so export the target site’s settings first if you want a backup. Remember that database indexes are created per site and aren’t part of the settings export – after importing settings on a new site, still create the indexes from the Indexes tab there.

How many database queries should a page have?

There’s no hard rule – the database is usually on the same server over a socket, so even a couple of thousand queries can be fast, and a high count is a symptom rather than always a problem. As a guide, aim for under 300, ideally under 100, and under 20 with an object cache (for reference, foundthru.com runs around 120 and this site around 80). If a count looks wrong, use Query Monitor’s “Queries by Component/Caller” to spot a plugin doing an N+1 loop (one list query followed by one query per row). Product variations push the count up, so keep variations to items that genuinely need their own SKU, image or independent stock.

Licence questions: staging sites, renewals and “too many domains”

You can install and activate Scalability Pro on as many dev/staging sites as you like – just download the zip from your account and upload it manually (automatic updates only run on the number of sites you have licences for). If your key reports “expired” or “exceeded”, free up unused domains from the account area, or message us with your key and domain. Renewals have a one-month grace period after expiry; if the renewal emails don’t reach you, message us on Discord for a 25% renewal coupon. Legacy lifetime licences are always honoured.

What hosting do you recommend?

Use a control-panel host so you own your server and can add disk and resources as you grow – GridPane or RunCloud, on top of a provider like Hetzner or Digital Ocean (prefer NVMe disks; Vultr where DO lacks NVMe). Round it out with a FastCGI page cache, a Redis object cache and Cloudflare edge caching in front. The key point is that control-panel hosts don’t earn more when you upsize, so their interests line up with yours. Avoid splitting your database onto a separate server or offloading images to S3 to “save money” – with hundreds of DB calls per page, the added latency makes WordPress slower and usually costs more, not less. Our full stack guide is here.

Got an error rather than a question? See the Troubleshooting guide, or ask on Discord.