Three ways to model a graph

Graph databases have been around for some time now, and lately have been getting a lot more attention. Given that, it feels a good time to talk about some of the key distinctions. We tend to view them as three distinct approaches to graph modelling, with different strengths and limitations.

Labelled Property Graphs

Some examples: Neo4j, Amazon Neptune, ArangoDB, Memgraph

LPG is what most people think of when someone says “graph database.” The model is built on data held in nodes and binary edges. Nodes and edges can then carry specifically assigned key-value properties to add further information.

The design priority here was always developer ergonomics and traversal performance. LPGs are very good at path-finding problems. If your core question is “how are these things connected, and how quickly can I find out,” LPG is very good at that.

Some limitations show up when your domain gets more complex than the model can cleanly express. Relationships in LPG are binary, which isn’t always the case. For instance, a financial transaction doesn’t just connect a buyer to a seller; it involves a product, a time, a jurisdiction, a payment method. In LPG, you either denormalise that into properties on the edge (losing the ability to query those dimensions as first-class entities) or you start adding intermediate nodes to represent the relationship itself, and then connect the concepts that way. Since all nodes are equal, this can create some degree of computation overhead.

There’s also no enforced type system. Labels exist, but they’re more like tags than types. You can’t enforce that a Person has a name, or that a Transaction must reference an Account. That enforcement has to live in your application layer, which means it often ends up inconsistent, incomplete, or both. At scale, this becomes a query performance liability too; without schema, the engine has no semantic shortcuts when queries get abstract, and falls back to broader traversal than a typed system would require.

Of the three, LPGs have the largest ecosystem, with strong tooling, community, and operational support.

OWL and the semantic web

Some examples: Stardog, Ontotext GraphDB, Apache Jena, Cambridge Semantics Anzograph

OWL (Web Ontology Language) comes from a different approach entirely. It was built specifically for knowledge representation, centred around formal logic, academic research, and is the foundation for the semantic web. The underlying data model uses RDF triples: subject, predicate, object. 

OWL operates under the Open World Assumption (OWA): if something isn’t stated, it’s not known rather than incorrect. For some problems that works very well, as it allows for natural knowledge extensibility, and tolerates incomplete data without immediately failing. If you’re building products where incomplete data should trigger an error, you have to layer validation on top of the store manually. Tools like SHACL exist to address this, though they add another layer of complexity.

When data is expressed in a shared ontology, systems that have never met each other can reason about the same concepts. In contexts where data crosses organisational boundaries this becomes very helpful. OWL also supports formal reasoning: you can define that every Manager is an Employee and have the system infer things that weren’t explicitly asserted.

One common issue is that SPARQL has a longer learning curve, and can be quite complex to work with and iterate on. The tooling ecosystem, while mature in academic circles, hasn’t translated well to production engineering teams to date.

TypeDB: a third way

TypeDB starts from a different angle. It uses a strict type system, where every data concept can be defined under the PERA model. Everything can be defined as an entity, relation, or attribute, all of which are first class concepts and can inherit from other types.

This means you can model the fact that a CurrentAccount is a kind of BankAccount is a kind of FinancialInstrument, and queries, validation, and functions all respect that hierarchy without you having to manually replicate it everywhere.

Rather than optimising for traversal speed or formal interoperability, it optimises for modelling expressiveness. The core thesis is that most of the complexity in building data-intensive systems comes from the gap between how your domain actually works and what your database can cleanly represent.

TypeQL, TypeDB’s native query language, is built around the same principles developers already use (types, inheritance, polymorphism). For teams coming from object-oriented or strongly typed languages, the learning curve is relatively shallow.

TypeDB operates under the Closed World Assumption (CWA). So, if something isn’t in the database, it doesn’t exist. All types have to be defined intentionally in the schema. Uniquely, TypeDB will throw an error if you try to insert data that doesn’t match the schema, which provides significant guardrails that don’t exist in LPG or OWL.

There are two main tradeoffs with using TypeDB. The first is that the schema has to be defined first, before data is inserted. This means more upfront work, but this typically pays back significantly over time.

The other tradeoff is that TypeDB is still a relatively young ecosystem. The community is active and growing, but it’s small compared to Neo4j’s. If you need battle-hardened tooling and a large talent pool on day one, then it’s unlikely the right choice for you.

Comparison

AI suitability

As AI agents and LLM-powered systems increasingly interact with databases directly and deeper into these stacks, reading schema, generating queries, reasoning over data, the structure of the underlying model matters more than it used to.

LPG’s schema-optional model gives an AI agent very little to reason about. Without a formal type system, an agent exploring a graph has to infer structure from patterns in the data itself, which is slow, unreliable, and brittle when the data is inconsistent. Cypher generation from natural language is possible, but the absence of schema means there’s no contract for the model to anchor on.

OWL’s formal ontology is arguably the most theoretically suited to machine reasoning. The challenge here is practical, rather than conceptual. The overall verbosity of RDF and the complexity of SPARQL make it difficult to use reliably in agentic contexts. The Open World Assumption is also a problem: an AI agent that can’t distinguish between “this doesn’t exist” and “we don’t know if this exists” has a structural tendency toward hallucinations.

TypeDB’s typed schema is essentially a machine-readable contract. An AI agent can inspect the schema, understand what types exist, what relationships are valid, and what attributes are required, and generate queries that are more likely to be structurally correct, reducing the validation overhead that schema-less systems push back onto the application. The Closed World Assumption means the agent can trust what the database returns.

So which one is best?

The honest answer is that it depends on what your primary problem is.

If your problem is pure traversal, LPG is mature, well-tooled, and fast. 

If your problem is interoperability across organisational boundaries, and you’re prepared to invest in major ontology work, OWL/RDF is a good path.

If your problem is modelling complexity, n-ary relationships, or where data correctness needs to be enforced at the database layer, then TypeDB was built for that.