Where should product data live: the platform, a PIM, or an index?
Date Published
Product data should live in three places, each doing a different job. The PIM or ERP is where it is authored and kept correct. The index is where it is assembled, enriched, and answered from. The ecommerce platform holds only the slice needed to take an order. Most large-catalog problems come from asking one of these three to do another one’s job.
The three jobs
- Authoring. Someone has to own the approved value of every attribute, who changed it, and whether it passed validation. That is a PIM, an ERP, or a DAM for media. Normalised, workflow-driven, slow to query, and correct.
- Answering. Someone has to say, in milliseconds, what you have, what fits, what it costs this customer, and whether it can ship. That is an index. Denormalised, enriched with derived facts, fast, and rebuilt from the sources whenever they change.
- Transacting. Someone has to take the order accurately: SKU, price, tax, inventory, address, payment. That is the platform. It needs a product record shaped for checkout and nothing more.
Why the platform cannot be the system of record
A platform’s product model is shaped for checkout. Rich attributes, relationships, synonyms, fitment, and relevance signals are bolted on, if they exist at all. Every extension that adds one adds a table, a screen, and a sync job. The platform can hold a copy of the truth, but at large-catalog scale it cannot be the truth, because the truth has more shape than the model allows.
Why the PIM cannot be the index
A PIM answers “is this attribute approved and who changed it”. It does not answer “which of these forty thousand products fits a 2019 F-150 with the 20-inch wheel package” at request time. It is not built for that shape of question, and the export jobs that carry data from a PIM to a storefront run through the narrowest field map in the chain. Whatever survives that map is what the customer gets.
This is the gap most merchants have paid for without noticing. They have spent real money on correctness and nothing on usefulness, and then wonder why governance never showed up in revenue.
What the index holds that nothing else does
The index is the only place where derived facts can live. Fitment resolved to a vehicle rather than a spec sheet. Units normalised so a search for 3/8" finds the product listed in millimetres. Compatibility relationships between products. Synonyms and part-number variants. Ranking signals. Generated content and structured markup. None of that belongs in a PIM, because none of it is authored, and none of it fits a platform, because none of it is needed to take an order.
A simple test
Can you answer, in one query and without touching the platform: what do we have, what does it cost for this customer, and can we ship it? If the answer is no, you do not have an index yet. You have a search plugin that builds one as a side effect of syncing, assembled from the data it could reach rather than the data it needed.
What changes when the index is deliberate
- One place to fix things. A missing attribute is corrected once and shows up in organic pages, site search, feeds, and structured markup together.
- New channels get cheap. The next surface is a new reader of an existing index, not another integration into the transaction database.
- The platform becomes swappable. When the storefront and the channels read from the index, the platform is one consumer of it. Replatforming is a checkout migration, not a catalog migration.
The longer version of the argument is in why a spreadsheet import will not make you findable and API-first is backwards. The practical consequence for architecture is the subject of headless or monolith for a large catalog.
How vector (similarity) search improves personalization, visual search, synonym handling, discovery, and speed for modern e-commerce.
API-first inverts the dependency chain. Own your data model on an index, and the API takes care of itself — the durable way to build commerce at scale.