The plugins, the architecture decisions, and the import pipeline we use to keep large-catalogue WooCommerce stores running fast and accurate.
WooCommerce scales further than most people expect — but it requires a different approach than a 200-SKU store. We've built and maintained catalogues in the 15,000–50,000 SKU range on WooCommerce, and the problems are consistent enough to write a playbook.
WooCommerce's default setup stores product data across multiple WordPress tables with a post-meta architecture that becomes genuinely slow at scale. A product query that's imperceptible on a 500-product store can take seconds on a 20,000-product one.
The first thing we do on any large-catalogue build is audit query performance. The usual culprits: unindexed meta queries used for filtering, no object caching layer, and product category queries that JOIN across multiple tables without limits.
Solutions in order of impact: Redis object caching (via WP Redis or similar) eliminates the majority of redundant database reads. Elasticsearch-based search (Jetpack Search or a self-hosted instance) replaces WooCommerce's default search, which doesn't scale. For filtering, we use custom taxonomy tables rather than meta queries wherever possible.
At 20,000 SKUs, product data doesn't come from a person typing into WordPress admin. It comes from a supplier feed, a PIM, or an ERP. Building a reliable import pipeline is where most large-catalogue projects either succeed or become a maintenance burden.
We standardise on a three-stage pipeline: extract (pull data from source in its native format), transform (normalise to a consistent schema, handle duplicates, validate required fields, map supplier categories to site categories), and load (upsert to WooCommerce via WP CLI or the REST API, with error logging and retry logic).
The critical detail in the load stage: use WP CLI for bulk operations, not the admin UI. wp wc product create in batch mode is orders of magnitude faster than any UI-based approach and doesn't time out.
Products with many variations (colour × size × material, for example) create exponential SKU counts quickly. A product with 5 colours, 8 sizes, and 3 materials is 120 variations. At scale, this creates performance and UX problems.
Our approach: limit stored variations to combinations that actually exist in inventory. Don't auto-generate all permutations. Build a configuration UI that shows only valid combinations based on real stock data. This reduces the variation table size by 60–80% in most catalogues.
At this scale, inventory is usually managed in an ERP or warehouse system, not WooCommerce. Real-time sync via webhook is the right architecture — stock changes in the ERP trigger an API call that updates WooCommerce within seconds. Batch sync (hourly or daily) is a fallback, not a primary strategy. Overselling due to stale stock data is a real cost.
WooCommerce at this scale requires ongoing maintenance. Database optimisation, plugin compatibility management, and import pipeline monitoring are regular tasks. If you don't have a development team or agency handling this, the operational overhead will outweigh the platform flexibility benefits. At that point, Shopify Plus with a PIM integration is often a better answer.