Ecommerce for large catalogs
Past about ten thousand SKUs, the ecommerce platform stops being the centre of the architecture. Product data lives in an ERP or a PIM, search lives in a separate index, pricing comes from the ERP, and the platform takes the order. The asset is the index where all of that converges. This is how to build around it, whatever platform you are on.
The short answer
A large catalog is not a bigger version of a small one. It is a different problem. The platform admin cannot be where product data lives, the product model cannot hold the attributes that matter, native search cannot answer the questions customers ask, and every channel needs a different shape of the same data. Teams solve each of these separately, with an extension, a plugin, and a sync job, and end up with five copies of the truth that disagree.
The alternative is to treat the searchable catalog as infrastructure: one index, built deliberately from the systems that author product data, that every surface reads from. The storefront, site search, feeds, structured markup, and whatever answers customer questions next all become readers of the same thing. The platform becomes one of them, and its job narrows to checkout.
This is platform-agnostic on purpose. It applies on Shopify, BigCommerce, Adobe Commerce, or a custom stack, and it is the approach behind Neuron, the index-first product we are building.
What actually goes wrong•
These arrive in a predictable order, and the first three are usually already happening by the time anyone asks for help.
The three layers to own•
Own these and the platform becomes a component you can swap. Rent them and the platform owns you.
The index
One canonical, enriched representation of the catalog, built from the ERP, the PIM, and supplier feeds.
- Derived facts: fitment resolved, units normalised, relationships explicit
- Every surface reads from it, so a fix propagates once
- Portable across platforms, which is what makes replatforming cheap
Search and answers
Site search, category pages, feeds, and whatever answers customer questions next, all served from the index.
- Relevance and merchandising logic in version control, not a vendor dashboard
- No per-request meter that grows with success
- Ready for agents and answer engines, because the facts are structured
The front end
Reads product, category, search, pricing, and availability from the index, and nothing product-shaped from the platform.
- Cheaper than it has ever been to build, and getting cheaper
- Where brand and conversion live, so it should be yours
- Platform reduced to cart, checkout, payments, and orders
The series
Each of these answers one question. Read them in order or jump to the one you are stuck on.
- What breaks in ecommerce platforms past 10,000 SKUs
- Where should product data live: the platform, a PIM, or an index?
- Headless or monolith for a large catalog? How to decide
- What drives the cost of a large-catalog ecommerce build
- How to migrate a large catalog without losing search traffic
Background reading: why a spreadsheet import will not make you findable, API-first is backwards, and headless is turning platforms into checkout companies.
Tell us about your catalog
Send us your SKU count, where product data is authored today, and which channels read it. We will tell you what an index-first build would look like for you, including when the honest answer is that your current setup is fine.