Scaling WooCommerce past 50,000 products

WooCommerce has a reputation for struggling with large catalogs. Some of that reputation is earned, mostly by stores built with default settings and too many plugins. Some of it is outdated. We run WooCommerce stores with 50,000 to over 200,000 products that load quickly and handle sale-day traffic without drama. The difference is not a secret plugin. It is a handful of architectural decisions made early and maintained deliberately.

Where large catalogs hurt

Performance problems in big WooCommerce stores cluster in predictable places:

• Product queries on post meta. Filtering by price, stock or attributes through meta queries becomes slow as the meta table grows into tens of millions of rows.
• Layered navigation. Attribute filters that count matching products for every option on every page load are expensive.
• Search. Default WordPress search uses LIKE queries against post content and scales poorly, with weak relevance.
• Imports and syncs. Nightly feeds that update every product, rather than only what changed, lock tables and invalidate caches.
• Autoloaded options and transients. Plugins that store large amounts of data in autoloaded options slow down every request, logged in or not.

Database and data model decisions

The foundation is a clean data model. We make sure the store uses WooCommerce's product lookup tables and High-Performance Order Storage, which moves orders out of the posts tables into dedicated, indexed tables. For stores migrating from older versions, enabling HPOS is often the single biggest improvement to admin performance, especially on order screens.

Beyond that, we apply a few rules consistently:

1. Use global attributes, not custom per-product attributes, for anything customers filter by. Global attributes are taxonomies and can be indexed; custom attributes are serialized meta.
2. Keep variation counts sane. A product with 400 variations is usually better modeled as several products or as a configurator.
3. Audit post meta regularly and remove orphaned rows left behind by uninstalled plugins. We have cleaned stores where more than 40% of meta rows belonged to plugins no longer installed.
4. Add database indexes where query analysis justifies them, and document them so they survive migrations.
5. Run the database on properly sized managed infrastructure with enough memory for the working set.

At scale, WooCommerce performance is mostly a data modeling problem that looks like a hosting problem.

It is also worth auditing the admin side, not just the storefront. Large stores often suffer from slow product edit screens and order lists long before shoppers notice anything. Disabling admin dashboard widgets that run heavy report queries, limiting the number of products shown per admin page, and moving analytics to a dedicated reporting tool instead of live queries on the production database all make a noticeable difference to the team's daily work.

Search and filtering off the database

For catalogs of this size, we move search and faceted filtering to a dedicated search engine such as Elasticsearch, OpenSearch or a hosted equivalent. Products are indexed on save and through a queue for bulk changes, and the storefront queries the search index for search results, category listings and filters. The database is only asked for data on individual product and cart pages.

This change typically takes category pages with several active filters from one to three seconds of server time down to under 200 milliseconds, and it brings real relevance tuning: synonyms, typo tolerance, boosting in-stock and high-margin items, and merchandising rules the team can adjust without a developer.

Caching that respects the cart

Full-page caching is essential, and in WooCommerce it has to be done carefully. Product and category pages are cached at the edge for anonymous visitors, while cart, checkout and account pages bypass the cache. Cart fragments, the default mechanism that updates the mini-cart on every page, often defeat caching entirely; we replace them with a lightweight approach that only fetches cart state when a cart cookie exists.

Object caching with Redis handles the repeated database lookups that remain. Price and stock changes trigger targeted cache purges for the affected product and its categories, rather than clearing everything. On one store, moving from global purges to targeted purges raised the edge cache hit rate from around 55% to over 90% during a sale week.

Finally, we load test before every major sales event, replaying realistic traffic patterns that include search, filtering, adding to cart and checkout, rather than hammering the home page. The goal is to find the first bottleneck at two to three times the expected peak, so there is room to spare on the day.

Imports, syncs and operations

Large catalogs are rarely managed by hand. They are fed from an ERP, PIM or supplier feeds, and the import process can make or break performance. Our standard approach:

• Import deltas, not full catalogs. Compare incoming data with a hash of the current state and only write products that changed.
• Process updates through a background queue in batches, outside peak hours when possible.
• Pause search indexing and cache purging during bulk jobs, then reindex and purge once at the end.
• Log every run with counts of created, updated, skipped and failed products, and alert on anomalies such as a feed that suddenly drops half the catalog.

That last check has saved more than one client from publishing an empty store after a supplier sent a truncated file.

For one home goods retailer with about 85,000 products, these changes together reduced median category page response from 2.4 seconds to 180 milliseconds, cut the nightly import from four hours to 25 minutes, and let the store handle a promotional peak of roughly six times normal traffic without scaling incidents.

This work typically combines our WooCommerce builds team with ERP and inventory integration for the feeds and database scaling for the infrastructure underneath.

Talk to us about your catalog

Share your product count, order volume and the pages that feel slow today. We will reply within 24 hours with a fixed-price quote for an audit or a full performance program.