Introduction to TypeDB

TypeDB looks beyond relational and NoSQL databases by introducing a strong type system and extending it with inference and pattern matching for simple, yet powerful querying.

TypeDB brings the benefits of strong typing to databases

We believe strong typing must extend to databases. It’s a core concept in the programming languages we love – from Java and Kotlin to Rust and TypeScript – and it lets developers write efficient and flexible code using abstraction, inheritance and polymorphism. However, because databases lack type systems, there’s a mismatch between logical and physical data models.

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23

define

credential sub attribute, value string;
username sub attribute, value string;
email sub attribute, value string;

subject sub entity, abstract, owns credential;
user sub subject, abstract, owns username;
employee sub user, owns email;

insert $e isa employee, 
   has credential "passwd", has username "jdoe", has email "[email protected]";

In TypeDB, developers can define entities, relations and attributes as subtypes of others in order to inherit attributes and roles (e.g., employee inherits username from user). This allows attributes and roles, and any constraints on them, to be reused and easily maintained because they are only defined once. Further, developers don't have to insert data in multiple places for subtypes (or make sure they specify every supertype of a given subtype).

Over time, physical data models become even less logical because of database optimizations such as normalization and workarounds such as a lack of many-to-many relationships in document databases. The result is a database which doesn’t understand its own data and how its related. For example, schemas in relational databases can define foreign key constraints, but they're unaware of the context behind the relationship (e.g., inheritance).

MongoDB is no different with its $lookup stage. These databases know next to nothing about their own data. TypeDB was built to fix this problem. It has a strong type system based on logical data models: entities, relations and attributes. And by making relations and attributes first-class citizens, TypeDB is able to understand the nature of its data and how it's all connected – making it easy for developers to find what they’re looking for.

TypeQL queries are fully declarative via composable patterns

TypeDB’s query language, TypeQL, is based on pattern matching. To find data, developers combine patterns to describe what they’re looking for. It is fundamentally different than SQL queries which are long statements telling the database what to do and how. As a result, TypeQL is a truly declarative query language – simply describe the data to be returned, and TypeDB will figure out the rest.

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23

# find all files in the /usr/bin directory which 
# John Doe has permission to write
match
   $e isa employee, has email "[email protected]";
   $f isa file, has path "/usr/bin/"; 
   $a isa action, has name "WRITE";
   $ac ($f, $a) isa access;
   $p ($e, $ac) isa permission;

There are no joins, unions or even WHERE clauses in TypeDB's query language, TypeQL, because it's fully declarative and based on pattern matching. All developers have to do is describe the entities and/or relations they're looking for. TypeDB will figure out how to find them. Further, TypeQL queries are fully composable such that individual patterns can be added or removed to modify the results and each pattern is independent of the others.

Queries are created by combining discrete patterns, making TypeQL not only declarative, but composable. For developers, writing a query requires little more than coming up with a set of patterns that describe the data they're looking for. And troubleshooting queries is as easy as adding or removing patterns in order to change the results of a query. However, though easy to use, TypeQL is a powerful query language – supporting conjunction, disjunction and negation of patterns as well as grouping and aggregation of data.

Further, it does away joins, unions and recursive CTEs so developers don't have to waste time trying to comprehend and troubleshoot long query statements. Rather, the expressiveness of TypeQL expressiveness, combined with a type system and inference, allows developers to simply describe what they’re looking for – not what it is, not how to find it and not how it's all connected. As a result, developers don't have to worry about getting bogged down by complicated queries or writing code to handle database shortcomings.

TypeDB infers data on behalf of developers, simplifying data access

The age of AI is upon us, and it necessitates intelligent databases. It's not enough for databases to simply store data and provide a means to access it. The future will be built on those that are capable of reasoning over their data too. TypeDB's type system, combined with built-in reasoning engine, allows it to infer data on behalf of developers – putting deep information in plain sight.

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23

# find all of Jane Doe's permissions on restricted objects
match
   $e isa employee, has email "[email protected]";
   $p (subject: $e) isa permission, has restricted true;

TypeDB can infer attributes and relations for developers. In effect, its reasoning engine uses logic and rules to materialize abstractions that hide the complexity of interconnected data – making them easy to query. For example, restricted permissions can be inferred with business rules so developers can simply query for them rather than having to traverse the relations between subjects and objects, and then checking to see if those objects are restricted.

TypeDB is able to perform type inference, allowing developers to find data based on a shared supertype rather than specifying individual types. However, the real power of its reasoning engines lies in its ability to derive new information from existing data (i.e., to infer data that doesn't physically exist). TypeDB applies user-defined rules to existing data at query time. By embedding logic in these rules, developers don't have to incorporate it in queries – or even know about it.

The reasoning engine can materialize new attributes on an entity not only based on its other attributes, but on any relations it has to other entities (directly or indirectly) – and their attributes too. Further, it can materialize new relations between entities. The result is a layer of abstraction that hides the complexity of highly interconnected data so developers don't have to worry about specifying all of the potential permutations of connections to find what they're looking for.

Start building 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.