Types of Graphs: Which One Does What

Someone in the room says "we should use a graph for this." Four people nod, and at least two of them are picturing something different. One is thinking about a database that handles connected data quickly. One is thinking about a model of what the business means. Both are real things. They are not the same thing, and the conversation usually does not survive the discovery.

Here is the map, and what each layer is actually for.

What are the different types of graphs, and how do they relate?

There are two questions hiding inside "should we use a graph," and they sit at different levels.

The layers, from storage upward

• Relational databases. Data in rows and columns. Not a graph, but part of the picture, because most of your data lives here and is not moving.
• Graph databases. Data stored as nodes and edges, optimised for traversing connections. Two kinds sit underneath this heading.
• Knowledge graph databases. Graph stores built on open standards, where identity and meaning are part of the data model.
• Label property graphs. Graph stores where nodes carry labels and properties, and meaning is decided locally by the team that built it.
• The semantic authority layer. Not a storage choice at all. The governed model of what your concepts mean, which sits across every one of the above.

The first four are about where data lives and how fast you can traverse it. The last one is about whether anyone agrees what it means. That is why comparing a knowledge graph to a graph database often produces an unsatisfying argument: the two sit on different axes.

What is the difference between a relational database and a graph database?

A relational database stores data in tables and reconstructs relationships at query time through joins. It is mature, fast for well-understood access patterns, and it is where most enterprise data correctly lives.

A graph database stores the relationship itself as a first-class object. You are not rebuilding the connection each time you ask; you are walking it. For questions that are fundamentally about how things connect, and especially for questions several hops deep, this is the difference between a query that returns and one that times out.

Neither replaces the other. A business running fraud detection on a graph database is still running its general ledger on a relational one, and should be.

What are the two kinds of graph database?

This is the distinction most often skipped, and it is the one that decides whether your model can leave the team that built it.

Knowledge graph databases

Built on open standards. Every entity gets a globally resolvable identifier, so the same customer referenced from three systems is recognisably the same customer. The model is declared in the data using RDF and OWL, so a second system can interpret it without asking the first team what they meant. Rules can be expressed separately and declaratively with SHACL.

Label property graphs

Nodes carry labels and key-value properties. Fast to model, fast to load, and genuinely excellent for application work. Identity is local to that database, and what a label means is a decision recorded in application code rather than in the data.

Worth being accurate here, because the opposite is often claimed: property graphs are standardised. GQL became an ISO standard in April 2024. What that standardises is the query language and a type system, which is the tractable half. Agreeing what labels mean across an organisation is the harder half, and that is what the knowledge graph standards were built to carry.

What is the semantic authority layer, and why is it not a graph type?

Because it is not a place to put data. It is the agreement about what the data means.

It holds the concepts that run your business, the relationships between them, the taxonomies and reference data that give them structure, and the rules for where each definition applies. Crucially it also holds the governance around all of that: who owns a definition, who approved the last change, what it replaced, and which version a given answer was based on.

It sits across relational databases, knowledge graph databases and label property graphs alike, because your data does not live in one of them and your meaning should not either.

Who is each layer for?

Different layers, different buyers

• Relational and graph databases are chosen by engineering, on performance, cost and operational fit.
• Knowledge graph databases are chosen by architecture, on interoperability and whether the model will still be legible in five years.
• The semantic authority layer is owned by the data office, governance and the subject matter experts, because the value is the agreement, not the storage.

This is why a tools comparison between a knowledge graph platform and a graph database so often goes nowhere. The people evaluating them are solving different problems and are frequently not in the same meeting.

Which of these do I actually need?

Most enterprises of any size need more than one, and that is the normal outcome rather than a sign something went wrong.

The useful question is not which graph to buy. It is whether anything in your architecture currently holds the answer to "what does this company mean by an active customer, who decided that, and where does it apply." If the answer is that it depends which system you ask, you have a semantic authority problem, and no amount of storage will fix it.

Where does TopQuadrant fit?

We do not sell the graph your analytics run on. We build the layer above it.

TQ Data Foundation is where the model gets defined with the experts who own it, validated against declared rules, and made available to AI systems as authoritative context rather than a plausible guess. It runs on open W3C standards, which means the agreement it holds is portable rather than trapped. For the full picture, see our overview of knowledge graphs.