What breaks in ecommerce platforms past 10,000 SKUs

Past roughly ten thousand SKUs, an ecommerce platform starts failing in a consistent order: the admin stops being where product data lives, the product model stops fitting your attributes, native search gives up, category pages become the performance problem, and every channel you add makes another copy of the catalog. None of this is a defect. The platform was designed for a catalog a person can curate by hand, and yours is not one.

This is the list, in the order it usually shows up. If you recognise the first three, the rest are coming.

The admin stops being where product data lives

At a few hundred products, someone edits them in the platform admin and that is the truth. At ten thousand, nobody edits anything by hand. Bulk import becomes the interface, and every import is a lossy copy of something upstream: an ERP, a PIM, a supplier feed, or a spreadsheet somebody guards with their life.

From that point the platform is not the system of record. It is a cache of one, refreshed on a schedule, and every question about “what do we actually sell” gets answered somewhere else. Most teams do not notice this shift until the first time the import and the source disagree and nobody can say which one is right.

Attributes stop fitting the model

Platform product models are built for a handful of options per product: size, colour, material. A large catalog has attributes the model has no place for. Fitment. Units of measure and pack sizes. Compatibility with other products. Contract pricing per account. Multi-warehouse availability. Regulatory data.

The first response is extensions, and each extension brings its own tables, its own admin screens, and its own sync job. By the second year a serious B2B implementation has spent more on making the product model stop being wrong than on anything the customer can see.

Native search gives up first

Native search is usually the first thing replaced, because it has a hard ceiling. It cannot handle part numbers with and without dashes, units the customer types differently from the catalog, synonyms your sales team uses daily, or any query where the right answer depends on something other than the product text.

So a search vendor gets added. That vendor needs its own copy of the catalog, transformed its own way, and now there are two copies to keep in step. The search index quietly becomes the more useful of the two, because it is the only place where enrichment happened.

Category pages become the performance problem

Layered navigation over fifty thousand products means computing facet counts on every page view. Platforms cache their way out of this, and the cache holds until a sale, a price update, or a crawl invalidates it all at once. The pages that carry most of your organic traffic are the ones that fall over.

Feeds and channels multiply the copies

Google Shopping wants attributes the platform does not hold. Each marketplace wants a different shape. Each feed tool reads from the platform, transforms in its own way, and writes somewhere else. Five channels means five slightly different versions of the truth, each failing quietly and in a different direction.

Pricing and availability go back to the ERP

Contract pricing, tiered pricing, and real stock across warehouses are questions the ERP can answer and the platform can only approximate. Teams either sync constantly and accept the lag, or call the ERP at request time and accept the latency. Either way, the platform is now a middleman for the one number the customer cares about most.

What this adds up to

By year two the platform is one consumer of the catalog, not the owner of it. The storefront reads from a search index, pricing comes from the ERP, feeds come from a feed tool, and the platform takes the order. The thing you actually depend on is the index where all of this converges, and most teams have never treated it as infrastructure.

That is the argument for building the catalog around an index rather than around the platform, and the next question is where product data should live.