Why WooCommerce slows down as your catalog grows, and what actually fixes it

A WooCommerce store that felt quick with 200 products can crawl at 20,000. The usual response is to buy a bigger server, and the gain is smaller than anyone expects. Most of the slowdown comes from how WordPress stores product and order data, and a faster CPU does not change the shape of the query the database has to run.

Knowing the storage model tells you which fixes pay off and which ones just move the problem somewhere else.

Products live in a table designed for blog posts

WordPress keeps every product as a row in wp_posts, the same table holding pages, posts, menu items and revisions. Everything that makes it a product (price, SKU, stock level, weight, visibility, a long tail of flags) lives in wp_postmeta as a separate row per field, keyed by post ID and meta key. That is an entity-attribute-value layout. One product is not one row. It is one row plus fifteen to forty more, scattered through a table shared with every other post type on the site.

Why filtering on a meta value gets expensive

wp_postmeta is indexed on post ID and on meta key. The value column is not usefully indexed, because it is a long text column holding everything from a price to a serialised array. So a query asking for products under a certain price, in stock, sorted by price, has to join wp_postmeta once per condition, match on meta key, then read and compare values row by row. Add a third filter and you get a third join. The rows touched grow with the catalog, the joins grow with the filter count, and sorting on an unindexed value pushes the database into a temporary table. This query shape sits at the top of the slow query log on most large stores.

The lookup tables exist because of that problem

WooCommerce maintains a flattened lookup table alongside the meta, holding the few fields it filters and sorts on constantly (price, stock status, SKU, rating, sales count) as typed columns with real indexes. Catalog queries read that instead of reassembling the same answer from postmeta joins. The cost is that it has to stay in sync. After a bulk update or a direct SQL write it can drift, and products then vanish from the shop while still looking fine in the admin. Regenerating the lookup data is standard maintenance, not evidence of corruption.

Variations multiply every row count

A variable product with five sizes and four colours is not one product. It is a parent plus twenty variation records, each a post row of its own carrying its own meta for price, SKU, stock and image. Two thousand variable products in that shape mean forty thousand variation posts and hundreds of thousands of meta rows before a single order exists. Price ranges on a listing page have to consider every variation's price to find the minimum and maximum. A store with a modest product count can therefore perform like a much larger one.

Autoloaded options are charged to every request

Rows in wp_options carry a flag marking them as autoloaded, meaning they are read into memory on every request before anything else happens. Plugins use it freely. Uninstalled plugins often leave their rows behind. On a store with a few years of experimentation behind it, the autoloaded payload can reach several megabytes, and every page view, AJAX call and cron tick pays to fetch and unserialise all of it. Measuring the total size of autoloaded options takes minutes and is frequently the largest easy win available on an older store.

The admin gets slow before the shop does

Order data historically lived in the same wp_posts and wp_postmeta pair as products. Customer email, billing address, order total, payment method: all meta rows. An order screen that filters by status, searches a customer name and sorts by date is doing the same multi-join postmeta work as a filtered shop page, against a table that only ever grows. Staff feel it on the orders list first, then in order search, then in reports. Moving orders into dedicated tables with typed columns and proper indexes addresses it at the root, and WooCommerce ships that option. Treat it as a migration: test it on a copy, and check any plugin that reads order data with its own SQL, because those are the ones that break.

Object cache and page cache solve different problems

A page cache stores finished HTML and serves it to anonymous visitors without running PHP or touching the database at all. It does nothing for logged-in users, the cart, checkout or the admin, every one of which has to be excluded for the store to stay correct. A persistent object cache (Redis or Memcached) works a level lower, keeping the results of individual queries and option lookups in memory between requests, so the expensive work above happens once instead of once per visitor. Without one, WordPress still caches objects, but only for the life of a single request.

Adding page caching and stopping there is the common pattern. The shop front gets fast. Checkout, account pages and the admin stay exactly as slow as they were, because none of them were ever eligible for the cache.

The background queue nobody looks at

WooCommerce hands deferred work to a scheduled action queue stored in its own tables: emails, stock syncing, renewals, whatever plugins push into it. On a busy store those tables accumulate completed and failed entries in the hundreds of thousands, and the queue then competes with live traffic for database time. A failing action that retries in a loop is worse again. Queue size and queue health belong in routine maintenance checks.

Where to look first

1. Turn on slow query logging for a day, then read the top queries by total time. Most large stores find the same shape: a product or order query joining postmeta several times over.
2. Measure the total size of autoloaded options, and clear out rows left behind by plugins that are no longer installed.
3. Check whether a persistent object cache is running at all. Plenty of hosts advertise caching and mean page caching only.
4. Count variations, not products, when you describe the size of the catalog. The variation count predicts query cost far better.
5. Look at where orders are stored. If they still sit in the posts tables and the order list drags, that fix has the highest ceiling.
6. Consider a bigger server last, once you know which query you are trying to give more headroom to.

Front-end weight is a separate axis from all of this and deserves its own measurement. A page the database answered quickly can still feel slow because of uncompressed images and render-blocking scripts. Our Image Converter handles the format side of that, and the SEO Analyzer reports what a live URL is serving, which helps separate a server-side problem from a payload problem before you start optimising the wrong one.

Why does WooCommerce get slow as the catalog grows?

Because WordPress stores each product as one post row plus dozens of key-value meta rows, and filtering or sorting on those values needs a join per condition against an unindexed text column. Add variations, order meta and autoloaded options, and query cost climbs with catalog size instead of staying flat.