TypeDB: a strongly-typed hypergraph database
TypeDB is not the usual graph database. I followed its evolution for a very long time and still find it difficult to position it in a customer project. Most graph debates stop at “RDF vs. LPG” but TypeDB can best be seen as a strongly-typed hypergraph database.
To recap. RDF models the world as triples. Clean, W3C-standardized (lots of them…), brilliant for open, federated, web-scale data. Relationships are binary and the moment you need a relation with more than two pieces you’re reifying it with extra nodes. It works well, but it’s modeling around the paradigm, not with it. LPG’s fix the ergonomics with nodes and edges having properties (payload) and pleasant traversals. No meta-edges however. Plus, schemas are (usually) bolted on.
TypeDB’s, on the other side of the universe, has a polymorphic entity-relation-attribute model which treats relations as first-class citizens with true n-ary relationships. It’s a hypergraph. The query language is called TypeQL and is a declarative, near-natural language with recursive functions that generalize Datalog-style logic programming natively. What I do like here is that you get symbolic reasoning without a separate rules engine.
When does a company need this? Business domains where relationships themselves have structure and provenance, data that must stay strictly typed and validated as it evolves, not just eventually consistent with a schema. Agentic pipelines that need queries the type-checker can validate before execution.TypeDB’s analyze API exists precisely so an AI agent’s generated query fails safely.
The honest caveat: RDF still wins on open-world interoperability and SPARQL federation at true web scale. LPGs still win on ecosystem maturity and sheer developer familiarity. TypeDB is trading some of that breadth for modeling fidelity and built-in reasoning. It’s a real trade-off, not a free lunch. It’s something you either totally fall in love with or stay away from.
TypeDB: https://typedb.com