Why TypeDB isn't a graph, but it can behave as one

At first glance, TypeDB looks like a property graph database. You write queries as patterns between connected entities. You think in networks rather than tables. You follow relationships to uncover meaning. While TypeDB presents a familiar graph surface, the similarity ends there, and in fact it differs in quite fundamental ways.

The promise and limits of graph

The rise of graph databases was a reaction to the rigidity of relational systems. Graphs let us model the world as it actually is: full of interconnections, context, and many-to-many relationships. They gave developers a way to traverse complex structures quickly and to express questions in natural, intuitive form.

The simplicity that makes graphs powerful can also constrain them. Graph databases are syntactic systems. They describe how data is connected, not what those connections mean. A node labeled person might connect to another node labeled company through an edge labeled works-at, but the database has no formal understanding of what those labels imply. The schema, if it exists at all, is descriptive rather than prescriptive. It documents patterns rather than enforcing semantics.

As graphs scale, this limitation becomes structural. Without shared meaning, edges become arbitrary conventions. Projects grow opaque, data loses consistency, and reasoning across domains becomes fragile. Graphs are excellent at describing connectivity, but poor at expressing knowledge.

The point of deviation

TypeDB begins exactly where the graph model stops. However, instead of storing a graph structure directly, TypeDB’s schema builds an ontology; a formal, logical model of entities, relations, and attributes governed by types and constraints. The result looks like a graph, but behaves like a knowledge system. 

In TypeDB, relationships are first-class, typed relations that define the roles each participant plays. A parenthood relation explicitly distinguishes parent from child, both of which can have their own subtype hierarchies and properties. Because these roles are typed, the database can enforce consistency and infer applicable searches.

Inheritance is built into the core model. A software-engineer is automatically a subtype of employee, which itself might inherit from person. When you query for all employees, the database automatically includes engineers, designers, and other specialisations without the need for explicit traversal or manual joins. Even better: this means you can add new subtypes on the fly with 0 changes to existing workflows.

In other words, TypeDB connects data while also understanding how that data is structured, constrained, and derived.

From traversal to declaration

The most visible difference appears in the query language. Graph query languages such as Cypher or Gremlin are procedural: they describe a path to follow through the graph. TypeQL, TypeDB’s query language, is declarative and logical (procedural means telling a computer how to do something, while declarative means telling a computer what you want to happen). You don’t tell the database how to navigate; you describe the pattern of truth you’re interested in, and the system resolves it through reasoning.

For example:

match
  $p isa parenthood (parent: $x, child: $y);
  $x has name "Alice";
select $y;

looks like a graph traversal, but it’s actually a logical pattern resolved against a type hierarchy. This isn’t traversal, it’s deduction based on type information.

N-ary relations vs binary edges

The departure from property graphs doesn’t stop there. Graph edges are always binary: they connect one node to another. TypeDB allows n-ary relations, or hyper-edges, that connect any number of entities through a single logical construct.

In TypeQL, you can define an employment relation that connects an employee, an employer, a contract, and a period all at once:

define
relation employment,
  relates employee @card(1),
  relates employer @card(1),
  relates contract @card(1),
  relates period @card(0..1);

This is the natural form of the data model. The database understands that this relation links all four participants in a single fact, with typed roles and constraints which require presence of an employee, an employer, and a contract but makes the period optional.

Where graphs require breaking meaning apart to fit binary edges, TypeDB preserves it whole. That single shift – from binary to n-ary – changes what the system can represent.

Why semantics matter

For small datasets, having a database that understands your data might seem excessive. But as agentic systems take hold, embedded semantics become a powerful source of system intelligence. And as your model evolves, they become decisive.

Consider a financial intelligence graph tracking transactions, accounts, and entities. In a standard graph, a connection like transfers-to is just an edge. Whether it represents a payment, an internal fund move, or a laundering route depends entirely on how an analyst interprets it. There is no formal constraint ensuring that a transfers-to relation must link two account entities, or that its value must correspond to a recorded transaction.

TypeDB enforces those semantics through its schema. It can prevent invalid data from entering the system, maintain logical consistency as the model evolves, and encompass higher-order functions to query beneficial ownership chains or indirect fund flows, without writing new application logic.

This semantic grounding makes data trustworthy. It allows reasoning to scale where manual traversal cannot.

The illusion of similarity

Because TypeQL queries read like graph patterns, TypeDB can be mistaken for a graph database with extra features. In truth, the “graph” you see in TypeDB is a useful projection of a richer logical structure. The database presents data as a network because that is an intuitive human representation, but internally it operates with entities, relations, roles, and attributes as first-class citizens. 

This lens is deliberate. It lets developers approach TypeDB with a familiar database model while gradually discovering its deeper capabilities. You can start by thinking in graphs and end by reasoning in higher-level logic, close to your domain.

TypeDB, is in essence conceptual, ontological, and declarative. It can mimic the graph form while delivering something categorically different.

Why deviation is strength

By deviating from the graph model, TypeDB gains three properties that graphs cannot provide:

1. Expressive schema
   Every entity, relation, and attribute is typed and hierarchically organized. This enforces meaning across datasets and enables safe evolution of the model over time.
   
2. Abstraction and reuse
   Declarative query patterns, subtyping, and roles give you simple ways to modularize queries into reusable components. Let the compiler work out what parts of the database to search! Even better: you can push reusable searches and computations in functions in the database, improving maintainability, and simplifying applications.
   
3. Data integrity by design
   Because semantics are part of the model, invalid or inconsistent data cannot be inserted or queried. The database ensures that the world it represents remains coherent and gives you semantic violation errors otherwise.
   

These are category-defining differences. They turn the database from a container of data into a system of knowledge.

Implications for the future

The distinction between graph and knowledge isn’t just theoretical. As systems become more autonomous, interconnected, and intelligent, they require data that can reason about itself. Graph databases capture structure, but only systems with logic and meaning can participate in intelligent decision-making.

TypeDB’s deviation from graph makes it a foundation for that next layer. It allows developers to build applications that not only query relationships but understand their semantics. That is essential for domains like agentic systems, robotics, or cybersecurity, where inference and constraints matter as much as connectivity.

The future of data has to be both connected and conceptual. And that future requires databases that think beyond the graph.

Closing

TypeDB’s power lies in stepping away from the binary graph model. It preserves the intuitive experience of network traversal while grounding it in a logical, ontological framework that brings structure, inference, and integrity to your data.

Graphs showed us how to see connections. TypeDB shows us how to understand and use them.

Ready to build systems that truly understand their own data? Check out TypeDB Cloud, or download TypeDB CE to start building your first knowledge system. Alternatively, dive into the documentation to explore how TypeQL performs declarative searches against an expressive ontology.