Meet TypeDB and TypeQL

TypeDB is a strongly typed database with an intelligent reasoning engine to infer new data and a declarative query language based on composable patterns to find it easily.

The benefits of strong typing

TypeDB brings the benefits of strong typing in modern programming languages to the database, allowing developers to use abstraction, inheritance and polymorphism when modeling and querying data – and finally removing the mismatch between logical and physical data models.

Logical data model

Inheritance

Relations as data

Multi-valued attributes


define

# entities
employee sub entity, 
   owns full-name, 
   owns email,
   plays group-membership:member;

business-unit sub entity, 
   owns name, 
   plays group-membership:group;

# relations
group-membership sub relation,
   relates group, 
   relates member;

# attributes
full-name sub attribute, value string;
name sub attribute, value string;
email sub attribute, value string;

Model data naturally – as the entities, relations and attributes defined in an entity-relationship diagram. There's no need for separate logical and physical data models due to database limitations and operational optimizations (e.g., normalization). In TypeDB, the logical data model is the physical data model.

Learn More


define

# can be user or group
subject sub entity, abstract, owns credential;

# can be employee or contractor
user sub subject, abstract, owns full-name;

# full-name is inherited
employee sub user, owns salary;
contractor sub user, owns rate;

# can be users in business unit or role
user-group sub subject, abstract, owns name;

# name is inherited
business-unit sub user-group;
user-role sub user-group;

Take advantage of inheritance in the database the same way developers do in applications, and remove one of the most common and painful mismatches between the logical data model and its physical data model. As an added benefit, data can be queried using the same vocabulary which defines it.

Learn More


define

subject sub entity, abstract,
   plays sod-violation:of;

object sub entity, abstract, 
   plays sod-violation:on;

action sub entity, abstract,
   plays sod-policy:prohibits;

sod-policy sub relation, 
   owns name,
   relates prohibits,
   plays sod-violation:against;

sod-violation sub relation,
   relates of,
   relates on,
   relates against;

Contextualize relations, which are now first-class citizens. Relations define one or more roles played by entities, relations and attributes, each with its own name, and optionally have attributes too – just like entities, and well beyond a simple foreign key constraint.

Learn More


define

employee sub entity, 
   owns full-name,
   owns primary-email,
   owns email-alias;

full-name sub attribute, value string;

email sub attribute, abstract, value string;

primary-email sub email, value string;
email-alias sub email, value string;

insert $e isa employee,
   has full-name "John Doe", 
   has primary-email "[email protected]",
   has email-alias "[email protected]",
   has email-alias "[email protected]";

Use multi-valued attributes without having to create join tables or parse strings. If a person has multiple hobbies, create multiple hobby attributes. And since attributes exist independently of entities and relations, and are shared, there’s no need to create lookup tables. Simply query the database to find all attributes of a specific type (e.g., hobby).

Learn More

The ease of pattern matching

TypeQL is a fully declarative query language based on pattern matching. There is no need for developers to tell TypeDB what to do (e.g., joins). Rather, they use patterns to describe what they're looking for. And because patterns are composable, they can be reused and combined to create new queries.

Truly declarative

Composable patterns


# no need to union employee + contractor
# or join user to employee|contractor
match $u isa user;

# no need to recursively traverse a hierarchy of groups
match
   $u isa user;
   $ug isa user-group;
   $gm (group: $ug, member: $u) isa group-membership;

# no need to specify how permissions are granted
match
   $u isa user;
   $p (subject: $u) isa permission;

Just describe what you are looking for, and TypeDB will find it. You never have to influence how queries are executed, let alone explicitly tell the database what to do. TypeDB’s query language, TypeQL, is designed specifically for expressing what data looks like, not how to get it. There are no joins, no unions and no need for ordered query logic.

Learn More


match
   $u isa user, has email "[email protected]";
   $p (subject: $u, access: $ac) isa permission;

# add file and access patterns to narrow the results to permissions on files
match
   $u isa user, has email "[email protected]";
   $p (subject: $u, access: $ac) isa permission;
   $f isa file;                                         # narrow to files
   $ac (object: $f, action: $a) isa access;             # any action on files 

# add an attribute pattern to further narrow the results to WRITE permissions on files
match
   $u isa user, has email "[email protected]";
   $p (subject: $u, access: $ac) isa permission;   
   $f isa file;      
   $ac (object: $f, action: $a) isa access;                               
   $a has name "WRITE";                                 # narrow to writes

Combine discrete patterns to describe all of the data which should be included in the results of a query. Rather than rewriting or trying to edit a large, complex statement a la SQL, developers can change the results of TypeQL query by simply adding, removing or substituting patterns – making it so much easier to iterate and troubleshoot queries on the fly.

Learn More

The power of inference

TypeDB's built-in reasoning engine, a technology previously found only in knowledge-based systems, enables it to infer data on the fly by applying logical rules to existing data – and in turn, allows developers to query highly interconnected data without having to specify where or how to make the connections.

Polymorphic queries

Implicit data

Transitive relations


match $e isa employee, has full-name $fn, has salary $sa;

match $c isa contractor, has full-name $fn, has rate $r;

match $u isa user, has full-name $fn;

match $bu isa business-unit, has name $n;

match $ur isa user-role, has name $n;

match $ug isa user-group, has name $n;

match $s isa subject, has credential $cr;

Feel free to query data based on abstract supertypes. For example, a query on cars (a supertype) will return all sedans, coupes and SUVs (subtypes). And as new subtypes are added (e.g., crossover), they will automatically be included in the results of queries on their supertype – no code changes necessary. There’s no need to be explicit, and query every subtype.

Learn More


define

# infer implicit READ permission from explicit MODIFY permission
rule add-read-permission:
    when {
        $write isa action, has name "WRITE";
        $read isa action, has name "READ";
        $ac_write (object: $obj, action: $write) isa access;
        $ac_read (object: $obj, action: $read) isa access;
        (subject: $subj, access: $ac_write) isa permission;
    } then {
        (subject: $subj, access: $ac_read) isa permission;
    };


# grant Jane Doe explicit WRITE access on README.md
# she does not have explicit READ access on it
match
   $u isa user, has email "[email protected]";  # subject
   $f isa file, has filename "README.md";          # object
   $a isa action, has name "WRITE";                # action
   $ac (object: $f, action: $a) isa access;
insert
   (subject: $u, access: $ac) isa permission;

# find all users with READ access on README.md
# the results would include Jane Doe
match
   $f isa file, has filename "README.md";
   $a isa action, has name "READ";
   $ac (object: $f, action: $a) isa access;
   $p (subject: $s, access: $ac) isa permission;

Don’t worry about modeling data which can be inferred. For example, if a person plays a role in a marriage with no end date, we can infer their relationship status is “Married”. However, there is no need for a relationship status attribute on the person entity. If it doesn’t exist, TypeDB’s reasoning engine will temporarily materialize it when queried.

Learn More


define

# members of a user group are members of other user groups
# for which their user group is a member
rule transitive-group-membership:
   when {
      (group: $g1, member: $g2) isa group-membership;
      (group: $g2, member: $s) isa group-membership;
   } then {
      (group: $g1, member: $s) isa group-membership;
   };

# members in a user group inherit its permissions
rule subject-permission-inheritance:
   when {
      $s isa subject;
      (group: $g, member: $s) isa group-membership;
      (subject: $g, access: $ac) isa permission;
   } then {
      (subject: $s, access: $ac) isa permission;
   };


# Admins and Editors are user roles, and both have permissions
# Admins is a member of Editors

# create a new user, and add them to Admins
match
   $ur isa user-role, has name "Admins";
insert
   $e isa employee, has full-name "Jane Doe", has email "[email protected]";
   (group: $ur, member: $e) isa group-membership;

# Jane Doe has been granted NO permissions
# however, results will include permissions inherited from Admins and Editors
match
   $u isa user, has email "[email protected]";
   $p (subject: $u) isa permission;

Find data based on the existence of other data, even when you don’t know what that other data is or how its related. It’s often impossible to describe all of the ways in which things are indirectly connected. Thankfully, TypeDB’s reasoning engine can discover and traverse relations on its own, allowing it to infer data on your behalf.

Learn More

Get started today

Cloud or containers, a database with strong typing, logical abstractions and declarative expressions is minutes away.

Bring the future forward

And show the world what's possible with a strongly typed database.

Deploy