EdgeDB is a graph-relational database that aims to solve design problems posed by relational models such as relational models such as object–relational impedance. Tables are defined as object types with links representing dependencies between tables.
It is paired with its own query language EdgeQL, that provides composable queries (that are compiled into optimized SQL) and a simplified interface for database development. EdgeDB is powered by PostgreSQL in the backend and thus inherits its ACID compliance, reliability, and performance.
EdgeDB describes itself as a "graph-relational" database that inherits many characteristics from a relational DBMS. Data is represented as strongly-typed objects which are the equivalent of tuples in a relational DBMS. Each object has an associated immutable id, so it doesn't require an extra column for uniqueness. Objects contain properties, which is the same as attributes in a RDBMS. They are connected to one another via links, thus creating a graph of dependencies between objects. All values in EdgeDB are stored as strongly-typed sets with cardinality constraints and an associated type. This removes any distinction between scalar-valued and table-valued expressions (unlike SQL). As the underlying backend is PostgreSQL, all object type and links are converted to tables for storage.
EdgeDB uses directional links to connect objects together, making them first-class members. These are can have the cardinality "single" (to-one) or "multi" (to-many) . Additionally, links can be "required" or "optional" and "exclusive" (no other link can refer to the same object). Thus, using the cardinality and exclusive constraints, all the relation types: one-to-one (single + exclusive), one-to-many (multi + exclusive) , many-to-one (single only), many-to-many (multi only) can be modeled. A user can also specify a backlink which allows them to access the relationship in reverse. Links can also have properties, which can be used to store metadata about the relationship.
In the backend, single links are represented as a column in the object type whereas multi links are stored in a separate association table, making single links marginally faster. Users can also setup deletion policies or triggers to delete a link if the source or target is deleted. Polymorphic links can allowing for abstract targets (OOPs style) while abstract links allow the source to be abstract as well.
EdgeDB supports indexes on single and multiple properties (columns/attributes) as well as arbitrary singleton expressions. Primary keys, links and properties declared with exclusive constraint are automatically indexed. Link properties can also be indexed.
Indexes are specified via
index on() in EdgeQL which is then compiled into
CREATE INDEX on PostgreSQL. EdgeDB supports hash, Btree, GIN, GiST, SP-GiST and BRIN indexes.
EdgeDB only supports serializable isolation. There is currently no plan to support other isolation levels, as their internal tests indicate very little performance gains.
EdgeDB does not have the concept of joins since it uses first class members called links to model connections between objects (see section on foreign keys). As such, different joins can represented as a path traversal across links (along with other graph based operations). This allows for deep, perfomant queries. Additionally, filters can use predicates on nested linked objects.
EdgeDB uses PostgreSQL as its backend and storage layer and so has the same disk-oriented storage architecture as PostgresSQL.
EdgeDB uses PostgreSQL as its backend and storage layer and so has the same n-ary storage model as PostgresSQL.
EdgeDB uses PostgreSQL as its backend and storage layer and so has the same storage organization as PostgresSQL.
EdgeDB uses PostgreSQL as its backend and storage layer and so has the same system architecture as PostgresSQL.