TypeDB Community Edition: a strongly-typed database that infers instead of joining

The problem TypeDB solves: schema-first data with inheritance

Most databases ask you to pick a shape up front. Relational engines normalize into tables and pay for it at query time with joins. Document stores keep a tree per record and lose cross-record structure. Graph stores keep nodes and edges but have no type system to speak of, so nothing stops an edge from pointing at the wrong kind of node. TypeDB's answer is to make the type system the center of the database: user-defined types subtype three root types, entities, relations and attributes, and the README describes relations as depending on role interfaces played by either entities or relations. That means a relation can participate in another relation, which is where plain graph models usually need workarounds.

The audience is narrow and identifiable. If you are building a knowledge base, a domain model with overlapping categories, or anything where the same query must return a base type and all its subtypes, TypeDB targets you directly. If your data is flat rows and your queries are aggregations over columns, it is the wrong tool and the type system is overhead you will pay for without using.

How TypeQL polymorphic queries work over the type hierarchy

The README's central example is polymorphism. A query written against `user` returns users of any subtype, while the same pattern written against `employee` returns only employees. That is not a view or a union: the query engine resolves the type hierarchy at query time, and the README shows a third form where the type itself is bound to a variable, `$user-type sub user`, so results carry their own type back to the caller. This is the feature that most distinguishes TypeDB from a property graph, where you would filter on a label field by hand.

Functions, introduced in TypeDB 3.0, are described in the README as modularizable subqueries you can reuse and invoke. They are the composition layer: instead of copying a pattern into every query, you name it once and call it. The README links to the TypeQL Functions documentation rather than showing a definition, so the exact syntax is something to read there, not something to infer.

The repository layout backs up the claim that this is a real engine rather than a wrapper. Top-level directories include `compiler/`, `executor/`, `ir/`, `query/`, `storage/`, `durability/` and `encoding/`, which is the shape you would expect from a database that compiles TypeQL into an intermediate representation and executes it against its own storage layer. The Cargo.toml confirms the binary crate is named `typedb_server_bin` and depends on `server`, `database` and `typeql` as workspace crates.

Installing TypeDB Community Edition and running a first schema

The README is explicit that you do not need to compile from source to use TypeDB. It points at GitHub Releases and at the installation documentation for the Community Edition. The repository does carry Bazel build files (`MODULE.bazel`, `WORKSPACE.bazel`, `.bazelrc`, `.bazelversion`) and a Bazel section in the README, but that path is aimed at people building the engine itself.

Once a server is running, the first real step is defining a schema. The README gives this example, which declares attributes, subtypes them, and wires up a mentorship relation between users and employees:

define

attribute full-name, value string;
attribute id, value string;
attribute email, sub id;
attribute employee-id, sub id;

entity user,
    owns full-name,
    owns email @unique,
    plays mentorship:trainee;
entity employee,
    owns employee-id @key,
    plays mentorship:mentor;

relation mentorship,
    relates mentor,
    relates trainee;

Note the two constraint annotations in that block. `@unique` on `email` and `@key` on `employee-id` are declared in the schema, so the engine enforces them on write rather than leaving it to application code. The `plays` clauses are what make the relation legal: a `user` cannot play the `mentor` role because the schema never grants it.

With that schema loaded, the polymorphic read is a single pattern. The README shows this form, which returns every user of any subtype along with the type that matched:

match $user-type sub user;
$user isa $user-type,
    has full-name $name,
    has email $email;

What you should see is one row per matching user, and the `$user-type` binding tells you whether the match came from `user` itself or from a subtype such as `employee`. Switching to `match $user isa employee, has full-name $name, has email $email, has employee-id $id;` narrows the same data to employees only. That pair of queries is the whole argument for the type system in two lines.

Where TypeDB Community Edition is the wrong choice

The edition split is the first limitation, and it is a hard boundary rather than a soft one. The README lists three editions: TypeDB Cloud as a multi-cloud DBaaS, TypeDB Enterprise for deploying TypeDB Cloud in your own environment, and Community Edition as the open source build in this repository. If your organization wants a managed database with someone else handling operations, or wants the Cloud deployment model on its own infrastructure, neither of those is this repository. The README routes both to the website and, for Enterprise, to an email address.

Second, the type system is not optional. Every attribute you want to query in a typed way needs a declaration, and every relation needs its roles defined before data can be written. For a schema that changes weekly, or a store of loosely structured events, that ceremony buys nothing. A document store or a wide table will get you further with less.

Third, the README is a marketing-forward document and it shows. It describes TypeQL as declarative, functional and strongly-typed, and the feature list leans on words like elegant and enjoyable. What it does not contain is any operational detail: no backup procedure, no rollback or downgrade instructions between releases, no memory or storage sizing guidance, no statement of what happens to an existing database when you upgrade across a major version. Those may well exist in the documentation site, but a reader deciding from the repository alone will not find them here. The release cadence is visible instead: 3.13.6 landed on 2026-09-22, 3.13.0 on 2026-09-08, and 3.13.0-rc0 on 2026-08-28, with the last push to master on 2026-09-22. Frequent point releases mean you should read RELEASE_NOTES_LATEST.md before moving a production database.

TypeDB compared with Neo4j and relational engines

The most common comparison is TypeDB against Neo4j, and the difference is structural rather than cosmetic. Neo4j is a property graph: nodes and relationships carry labels and key-value properties, and you traverse edges explicitly in Cypher. TypeDB puts a schema with inheritance and interfaces in front of the graph, so a query can ask for a supertype and receive subtypes, and a relation can itself play a role in another relation. In Neo4j you would model those cases with label conventions and extra relationship types, then filter in the query. TypeDB pushes that work into the schema, where the engine enforces it.

The trade-off is real in both directions. Neo4j's model is more permissive, which makes it faster to start and easier to change when the domain is still moving. TypeDB's model is stricter, which means schema mistakes surface at define time rather than as bad rows later. Against a relational engine the comparison is similar: TypeDB's README claims object model parity and the elimination of the object-relational mismatch, and the mechanism is that entities, relations and attributes map onto the concepts you would otherwise hand-write as tables plus an ORM layer. You give up the mature tooling around SQL, and you take on a query language that far fewer people know.

Licence and upgrade cost for the Community Edition

The repository is licensed MPL-2.0. That is a file-level copyleft licence: modifications you make to TypeDB's own source files must be published under the same terms if you distribute them, while separate files you add can carry other terms. This is not legal advice, and the practical question for most teams is narrower than it looks, because most teams consume TypeDB as a released binary rather than modifying the engine. If you do patch the engine and ship it, read the licence text in the `LICENSE` file at the repository root rather than relying on a summary.

Upgrade cost is dominated by the release cadence. Three releases appear in the recent history within about a month, including a release candidate. The repository has no documented downgrade path, and the README does not describe data format compatibility between versions. The concrete mitigation available from the repository itself is to pin a version, read `RELEASE_NOTES_LATEST.md` before moving, and keep the `RELEASE_TEMPLATE.md` structure in mind when filing anything upstream. For schema changes, the type system is your friend: adding a subtype is additive, but changing an attribute's value type is not something the README describes as safe.

Editorial conclusion

Adopt TypeDB Community Edition when your schema is the hard part: nested, polymorphic, inheritance-heavy data where SQL joins and graph traversals both get awkward. Do not adopt it if you need plain tabular reporting, a drop-in Postgres replacement, or a managed service without running anything yourself, since the README routes those needs to TypeDB Cloud or TypeDB Enterprise. Before committing, verify three things against the docs: that TypeDB 3.x functions cover the reuse you want, that your client language has a driver in the ecosystem list, and that the MPL-2.0 file-level copyleft terms are acceptable to your legal review. The README does not document rollback or downgrade between releases, so pin a version and read RELEASE_NOTES_LATEST.md before upgrading.

Frequently asked questions

Official sources

1. License: MPL-2.0
2. Project website
3. README
4. Releases
5. typedb/typedb on GitHub