Your Catalog Is Already a Graph. You Store It in Tables.

Every catalog you have exported looked like a table. Every decision your team makes with it is about a relationship: is this the same part, does this replace that one, which supplier is cheapest for the identical SKU. The table is just where you store it. The moment you ask a real question of the catalog, you are asking about edges.

Five ordinary operations, five kinds of edge

Look at what a catalog team does all day and every task is an edge being drawn.

Store those edges in cells and they stay trapped there: implied, unmaintained, lost at the next export. Store them as a graph, each one scored and sourced, and the catalog becomes something software and AI agents can traverse and trust.

What goes wrong when relationships live in rows

• Duplicates multiply. Nothing records that two rows are the same product, so the next import adds a third.
• Supersessions go unrecorded. A legacy part is quoted after it was replaced because the replacement was only ever in a buyer’s head.
• Specs drift from their source. A value is edited with no link to the datasheet that justified it.
• Knowledge leaves with people. The colleague who knew which housing fits which bearing changes jobs.

Tables are storage. Relationships are knowledge.

That is the shift behind Claro’s Product Identity & Evidence Graph. It is not another place to keep rows. It is a place where the relationships your business already depends on are finally written down, with evidence attached.

Do you need a graph database?

Not to start. The first win is conceptual: stop encoding relationships as free text and lookup columns, and give each one a type, a source, a confidence and a date. You can store that in relational tables, a PIM relation field or a graph store. Choose the technology when traversal queries (for example “everything compatible with this bearing, across all suppliers”) justify it. The practical walkthrough is in how to build a product evidence graph, and the longer argument against folders and flat files is in why product data belongs in a knowledge graph.

A five-minute test

Pick one product family and ask your catalog:

1. Which other records are the same product, and who decided that?
2. What replaces it if it is discontinued?
3. Which documents support its specifications?
4. What does it work with, and which are only look-alikes?

If any answer lives in a spreadsheet comment or a person’s memory, that relationship is not yet in your catalog. It is only in your business.

Related

FAQ

Why is a product catalog a graph? +

Because the questions a catalog answers are about relationships between products, suppliers, documents and attributes: which records are the same, what replaces what, what is compatible. A table can only store those implicitly, while a graph stores them as explicit, typed connections.

Do I need a graph database to treat my catalog as a graph? +

No. The shift is to record relationships as typed, sourced, scored data instead of free text or lookup columns. Relational tables, a PIM relation field or a graph store can all hold that, and a graph database becomes useful when you need multi-hop queries.

How does thinking in graphs help with product matching? +

Matching produces SAME_AS and NOT_SAME_AS edges instead of a disposable score. Those edges persist, so the next supplier feed attaches to existing identities and only new or ambiguous records need review.