why a knowledge graph vs a relational db

There is a conversation that happens in nearly every manufacturing digital transformation program, usually around the time someone proposes building a plant model. An architect looks at the requirement, looks at the stack, and says something reasonable: we already run Postgres, or Timescale, or Influx. Tables for equipment, tables for processes, foreign keys for the relationships. A knowledge graph is just nodes and edges, and an edge is just a foreign key. Why introduce a new class of system for something the relational model has handled since 1970?

It is a fair question, and the instinct behind it is sound. Good architects resist adding technology. The problem is that the equivalence at the heart of the argument, that a foreign key is an edge by another name, is wrong in a way that stays invisible during design and becomes expensive after deployment.

What a Knowledge Graph Actually Is

Strip away the vendor language and a knowledge graph is two things.

The first is an ontology: a set of types that describe what exists in your world and how those things can relate. 'Tank' and 'Pump' is a type. 'Feeds', 'isPartOf', and 'interlocksWith' are relationship types, defined with the same rigor as the entity types they connect.

The second is an instance model: the real things, Tank-101 and Pump-7 and the Line 2 pasteurizer, each an instance of a type, connected by instances of those relationships.

The property that makes this a knowledge graph rather than just a diagram is that the relationships are first-class objects. An edge has a type. It can carry properties of its own. Tank-101 feeds Reactor-3 is not a mere association between two rows; it is a fact with identity, and it can carry qualifiers such as "during fermentation" or "since the 2024 repipe." The meaning of the operation lives in the structure itself, and the structure can be queried directly: give me everything downstream of Pump-7, show me every interlock that touches Line 2, find any path between this alarm and that batch.

That is the whole idea. Entities, typed relationships as real objects, and a query surface that traverses structure. Everything that follows in this article about relational databases comes down to how each of those three elements maps, or fails to map, onto tables.

Foreign Keys Are Constraints. Edges Are Facts.

Here is where the architect's equivalence breaks. A foreign key is not a thing in a relational database. It is a constraint on things: a rule saying that a value in this column must match a value in that one. It has no type beyond the columns it joins, it cannot carry properties, it has no identity of its own, and there is no way to ask the database about it as an object. The relationship it encodes exists only in the schema, which means the meaning of the relationship exists only in the head of whoever designed the schema and whatever documentation they left behind.

An edge in a knowledge graph is the opposite. It is data. It exists as a record with a type, properties, and a lifecycle. You can create it, qualify it, version it, and query it without touching the schema. This sounds like a fine technical distinction, but it drives a consequence that decides the fate of the whole modeling effort.

Relationships as schema means every new kind of relationship is a design change. The plant discovers it needs to represent "shares a CIP circuit with," and the answer is a new join table, a migration, a change ticket, and a wait for the person who owns the schema. Relationships as data means the same discovery is an authoring action: a domain expert defines the relationship type and starts using it, and the model grows the way knowledge actually grows, incrementally and from the edges of the organization inward.

The Costs That Hide at Design Time

The relational approach does not fail at the whiteboard. On the contrary, the whiteboard phase goes beautifully, because a static snapshot of a plant maps onto tables well enough. The costs are structural, and they arrive in three forms.

Relationship types multiply, and each one is a table
A plant model does not have one kind of relationship. It has dozens: physical containment, material flow, electrical supply, control relationships, interlocks, procedural dependencies, calibration references. In a relational design, every many-to-many relationship type becomes its own join table, and the model's expressiveness is capped by how many of these anyone is willing to create and maintain. Teams respond in one of two ways. Either they under-model, collapsing distinct relationships into a generic "related_to" table that throws away the meaning the model existed to capture, or they reach for the entity-attribute-value pattern, storing everything as generic triples in a few giant tables. EAV is the relational world's confession that the schema could not hold the domain. It abandons typing, ruins query performance, and produces a database that is technically Postgres and practically an unindexed pile of assertions.

There is a third path, the diligent one, and it is worth playing out to its conclusion. Suppose the team refuses both shortcuts and commits to modeling every relationship properly. Material flow gets a table. Containment gets a table. Interlocks, CIP circuits, calibration references, electrical supply, each gets its own. Then the requirements arrive that any real relationship carries. Relationships need qualifiers, because Tank-101 feeds Reactor-3 only during fermentation, so each table grows condition columns. Relationships need validity windows, because the plant changes, so each table grows effective-from and effective-to timestamps. Some need direction, some need ordinal position, some need a reference to the change order that created them. Twenty relationship types become twenty tables carrying nearly identical scaffolding, each with its own indexes, its own insert paths, and its own variant of every query. Eventually a sharp engineer notices the duplication and consolidates: one table, with source, target, a relationship-type column, a JSONB field for qualifiers, and a pair of validity timestamps. It feels like a clean refactor. It is actually a surrender, because that table is an edge store. The team has hand-built a graph database inside Postgres, minus the type system, minus the traversal engine, minus the query language, on a storage engine tuned for exactly the access patterns the model no longer has. The diligent path and the EAV shortcut converge on the same place.

Traversal is the query you need and the query SQL punishes
The questions a plant model exists to answer are path questions. What is downstream of this valve? What does this interlock ultimately protect? Which batches passed through equipment that shares a lubrication system with the pump that failed? These are variable-depth traversals, and in SQL they become recursive common table expressions: hard to write, harder to review, and prone to performance collapse as the model grows, because the join cost compounds with every hop. A graph engine treats traversal as its native operation. The query says "follow feeds relationships downstream from Pump-7 to any depth," and the engine walks the structure. The difference is not elegance. It is whether the questions that justify the model are ones your engineers will actually be able to ask.

The schema assumes uniformity the plant does not have
Relational modeling wants populations of similar things: many rows, same columns. A plant is the opposite, a long tail of nearly-unique equipment where this tank has a jacket and that one does not, this line has an inline densitometer and its sister line uses lab samples. The relational responses are all bad: hundreds of near-empty nullable columns, a subtype table for every variation, or the EAV escape hatch again. A graph with a proper ontology handles variation natively, because types can be extended and instances can carry the properties they actually have.

What Happens After Deployment

Suppose the team pushes through anyway. The schema is designed, the migrations run, the model is loaded, and for a few months it works, because for a few months it describes the plant as it was on day one. Then the real world starts.

The first thing that happens is change. A pump is replaced, a line is repiped, a recipe moves to different equipment. In the relational model, updating the current state is easy, but the previous state is destroyed by the update. When quality asks how the system was connected in March, when Batch 47 ran, the honest answer is that the database no longer knows. Retrofitting structural history onto a relational model means temporal tables and validity intervals on every join table, which roughly doubles the schema's complexity and makes every traversal query time-qualified. A knowledge graph built for operations treats time as intrinsic: relationships have lifespans, and "the plant as of March" is a query parameter, not an archaeology project.

The second thing that happens is exceptions. Every plant model meets the one tank that violates the pattern, the temporary bypass that becomes permanent, the relationship that only holds during a particular product run. Each exception in a relational model is a schema decision, and schema decisions queue behind one owner. The migration backlog becomes the rate limiter on how fast the organization can describe its own reality, and domain experts learn that getting their knowledge into the model takes a ticket and a month. They stop trying. The model freezes at its day-one snapshot and quietly becomes wrong.

The third thing that happens is the quietest and the worst. The schema itself becomes tribal knowledge. Only the original architect (often contracted labor) knows why the join tables are shaped the way they are, which columns are trustworthy, and how to write the recursive query that answers a downstream-impact question. The system built to externalize operational knowledge has manufactured a new dependency on one person's head. Anyone who has read about knowledge governance will recognize the pattern: the failure mode was not eliminated, only relocated.

Where Relational and Time-Series Databases Still Belong

None of this is an argument against Postgres, Timescale, or Influx, which are superb at what they were built for. Time-series databases in particular are the right home for the value stream: millions of timestamped measurements, compressed, retained, and served fast. That job does not go away when a knowledge graph arrives, and pretending otherwise would be as naive as the foreign-key argument in reverse.

The same holds for the transactional systems of record. The MES, the LIMS, the batching system, and the ERP each exist to guarantee the integrity of a specific class of record, and relational databases are precisely the right engine for that job. Each of these systems validates its own records against its own rules: the LIMS enforces what makes a lab result valid, the MES enforces what makes a production event complete, the ERP enforces what makes a financial transaction balance. That segmentation by function is not an accident of procurement history. It is what makes each record trustworthy, because validation happens inside the system that owns the domain, independent of every other database and every other function's rules. Collapsing those records into one shared store, or asking one system to validate another's records, breaks exactly the guarantees the records exist to provide.

So the division of labor is clean, and it has three parts rather than two. The time-series store holds what happened, the values. The transactional systems hold what was done and attested, each validating its own records within its own function. The knowledge graph holds what things are, how they relate, and under what conditions the values and records mean anything, relating across those systems without absorbing or overruling any of them. Store values in the system built for values, keep records in the systems that validate them, and model meaning in the system built for meaning. The mistake is not 'using Timescale', and it is certainly not 'running a proper LIMS'. The mistake is asking any of them to be an ontology.

Building on a Graph That Was Built for This

The last honest objection is that general-purpose graph databases carry their own risks: another server to run, a data engineering skill set OT teams do not have, and a blank canvas where a plant model should be. This is the gap a manufacturing knowledge platform exists to close. Timebase Atlas is built around a knowledge graph engineered for operations, running on a custom backend designed for millions of objects and relationships rather than a repurposed general-purpose store, deployable on-prem, in the cloud, or at the edge. The ontology work does not start from zero, because standards libraries for ISA-95, ISA-88, and ISA-5.1 ship as pluggable starting points. Structure is queryable over Cypher while the underlying historian data flows through untouched, so questions like "which batches on Filler 3 last week ran with lab deviations during a temperature excursion" become one query across structure and values together.

Most importantly, the model is federated by construction. Relationship types and model slices are authored by the domain experts who hold the knowledge, in their own language, without a schema owner in the loop, and the slices compose into one coherent graph. That is the property the relational approach can never offer, because it is a property of treating relationships as data. The architect's instinct to avoid new technology is right most of the time. This is the case where the new thing is not an alternative implementation of the old thing. It is a different answer to what a relationship is, and everything your model will survive after deployment follows from that answer.