Your product catalog probably looks like this: SQL tables with a few hundred columns, joins everywhere, poorly defined JSON fields for "attributes we didn't know where to put," and a data team spending Monday mornings explaining why yesterday's query no longer returns the same results as the day before. This isn't a skills problem, it's a paradigm problem.
The problem nobody wants to admit
The relational model was designed to represent stable entities with predictable attributes. A physical product isn't that. A product is an object whose nature changes depending on the context you observe it from: a drill is a tool for a DIYer, a durable consumer good for an accountant, an object that could cause injury for an insurer, and an assembly of components for an after-sales engineer. All four readings are true, all legitimate, and all structurally different.
SQL, in its star or snowflake schema, forces you to pick one. A knowledge graph lets you hold all of them at once.
What SQL does well, and what it can't do
It would be dishonest to paint SQL as outdated. For analytical queries on stable, well-typed data, it's still the most robust option: nobody's going to model their sales aggregates in a graph. But the relational model's limits are structural, not circumstantial. They show up as soon as your data exhibits one of these three traits.
The three-layer architecture of a knowledge graph
Layer 1: entities and their types
Every concept in the domain becomes a typed node. A product is different from a variant, a component, a category or a brand. These types are defined in the ontology and inherit properties based on their position in the class hierarchy.
:Drill rdfs:subClassOf :PowerTool . :PowerTool rdfs:subClassOf :Product . :Product rdfs:subClassOf :CommercialEntity .
Meaning every rule that applies to a commercial entity automatically applies to a drill, without needing to repeat it.
Layer 2: semantic relationships
Graph edges aren't simple links. They're named, typed properties carrying a precise meaning: isCompatibleWith (symmetric), isVariantOf (functional, with a domain and codomain), requiresAccessory (with a mandatory true/false property), replaces (transitive in some contexts).
The difference from a join table? These relationships can be used by an inference engine. If A is compatible with B and B with C, you can define a rule that automatically infers A's compatibility with C, or conversely constrain non-transitivity if the business domain requires it.
Layer 3: rules and inference
This is the layer that turns a graph into knowledge rather than mere data. Two complementary languages operate here, and it matters not to confuse them: they don't act at the same level.
OWL models what things are and what you can infer from them. Declaring that a drill requires CE marking is enough for the reasoner to propagate that constraint to every instance, with no manual entry.
# OWL: every Drill requires a CEMarking :Drill rdfs:subClassOf [ a owl:Restriction ; owl:onProperty :requiresDocument ; owl:someValuesFrom :CEMarking ] .
SHACL doesn't deduce anything: it validates. It checks that data meets defined constraints and produces a violation report if not. It's the right tool for encoding a business rule like "every product in the construction materials class must have an environmental data sheet."
# SHACL: every construction material must have an environmental data sheet
:EnvDataSheetConstraint a sh:NodeShape ;
sh:targetClass :ConstructionMaterial ;
sh:property [
sh:path :environmentalDataSheet ;
sh:minCount 1 ;
sh:message "Environmental data sheet required for this product."
] .
In one sentence: OWL structures the knowledge, SHACL guarantees its quality. Both are complementary but don't operate on the same layer, and aren't interchangeable. These rules aren't application logic buried in your backend: they live in the graph, are versionable, auditable, and apply regardless of which application queries the data.
A concrete example: a B2B distributor's catalog
A distributor carries 400,000 SKUs from 300 suppliers, across 12 countries with partially different assortments, heterogeneous regulatory constraints, and a merchandising team that groups products differently depending on the channel: e-commerce site, PDF catalog, supplier EDI, internal ERP.
In SQL, this scenario invariably produces
- +A products table with 60 to 120 columns depending on the system's age
- +Overflow tables for attributes not planned for originally
- +Materialized views for e-commerce, different ones for EDI
- +Ad hoc transformation scripts for each country
- +Documentation that's always a version behind
In a graph, the same reality is modeled like this
# A product and its hierarchy :REF-42891 a :Drill ; :label "800W Percussion Drill SDS-Plus"@en ; :belongsToCategory :DrillingCategory ; :isVariantOf :MainModel-DWD524 . # A relationship with its context :REF-42891 :isAvailableIn :FranceMarket ; :withPrice "129.90"^^xsd:decimal ; :withCurrency :EUR ; :sinceDate "2024-01-01"^^xsd:date .
In Graphicient, business teams don't write SPARQL. The AI Chatbot module lets them query this same data in natural language, in a precise business context, using the graph to ground the LLM. "Which products in our tool range are compatible with brand X's 18V battery?" becomes a question asked in plain English, whose answer is verified, justifiable and auditable.
What the graph reveals that SQL will never see
The factor reshuffling the deck: LLMs
There's a more recent, more decisive reason to take this seriously: the main interface to enterprise data is becoming natural language. You ask a model "which products compatible with reference X are available in Belgium under €150?" and expect a correct answer.
Yet an LLM turned loose in text-to-SQL mode on an enterprise relational schema has to guess the meaning of cryptic table and column names, with no semantics to guide it. A graph, by contrast, carries meaning explicitly: nodes are typed, relationships are named in business vocabulary, constraints are readable. It's exactly the terrain a model needs to ground its answers.
The reference benchmark published by the data.world team quantifies the gap: a GPT-4 queried zero-shot directly on enterprise SQL databases gets it right in about 16% of cases; the same questions asked on a graph representation of those same databases push accuracy up to about 54%. A factor of three, based on the data model alone.
The role of the schema changes in nature. Its job is no longer just to store data, but to explain it to the machine reading it. And explaining the meaning of a piece of data is precisely what a SQL column can't do.
Common objections, and honest answers
"It's too complex for our teams"
Partly true. The ontology requires a serious upfront modeling phase, and SPARQL has a learning curve. But complexity also exists in SQL: it's just distributed differently, in ETLs, transformation scripts, informal documentation, and the heads of three people who've left the company. The difference is that in a graph, complexity is explicit and centralized; in a legacy relational schema, it's implicit and scattered.
"Performance won't keep up"
Modern graph databases (Neo4j, ArcadeDB, Neptune, Stardog, Oxigraph, MarkLogic) are built to traverse millions of edges in real time. For heavy analytical queries, a hybrid architecture remains possible: the graph for semantics and relationships, a columnar warehouse for aggregation. The real question isn't "is the graph faster than SQL" (on simple analytical queries, SQL always wins), but "which tool best fits the nature of my data." For product knowledge data, the answer is rarely SQL.
"Our suppliers don't speak RDF"
Nobody's asking you to expose Turtle to your suppliers. The graph is an internal layer; interfaces with the outside world (EDI, CSV, REST API) stay in their native formats. The mapping work between the supplier's raw format and the internal ontology is part of your semantic layer's added value.
Product data is inherently relational, hierarchical, contextual and evolving, and none of those four adjectives is the tabular model's strong suit. SQL will remain relevant for transactions, aggregations and exports. But to structure a catalog's semantics, what each product is, what it relates to, and what can be inferred from it, the graph addresses the problem at its root instead of working around it with JSON columns and ETL scripts. The question is no longer "why adopt a product knowledge graph," but "which part of the problem to start with."
Sources
- Neo4j, Graph Database vs. Relational Database: Key Differences (2025).
- InterSystems (2025) on the exponential cost of SQL recursion beyond four levels.
- N. Figay (2025) on the distinction between OWL and SHACL.
- Oxford Semantic Technologies (2024) on SHACL validation reports.
- Yakovets, Godfrey & Gryz (2013) on evaluating SPARQL property paths in recursive SQL.
- Vidal et al. (2025) on enterprise knowledge graphs as a semantic layer.