EdgeDB is a graph-relational database that aims to solve design problems posed by 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 generates composable queries (which are compiled into SQL) and a simplified interface for database development. EdgeDB is powered by PostgreSQL in the backend and uses it for its query engine and storage.


Yury Selivanov and Elvis Pranskevichus founded MagicStack, the parent company of EdgeDB, in 2008 as a boutique software development shop. Initially, the founders worked as consultants and developed a data layer Caos, that functioned as a "super" ORM. It featured an object oriented SDL and its own query language, CaosQL, that supported deep fetching and query composition.

From 2014-2018, MagicStack developed features to support fast Python async I/O such as async/await and uvloop. These were necessary to convert Caos into a full fledged database server. In mid-2016, they built asyncpg to support Postgres drivers in Python. With all the building blocks ready, they released their first preview at PyCon 2018. As of 2023, the latest version is EdgeDB 3.0.


Not Supported

As of 2023, EdgeDB does not support checkpoints.

Concurrency Control

Multi-version Concurrency Control (MVCC)

EdgeDB uses PostgreSQL as its backend and storage layer and so has the same multi-version concurrency control (MVCC) support as PostgreSQL.

Data Model


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 on their immutable ids, 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.

Foreign Keys

Not Supported

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.


B+Tree Hash Table Inverted Index (Full Text) Block Range Index (BRIN)

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.

Isolation Levels


EdgeDB only supports serializable isolation. As of 2023, there is no plan to support other isolation levels.


Nested Loop Join Hash Join Sort-Merge Join

EdgeQL supports using joins through PostgreSQL but its usage is generally discouraged 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). Additionally, filters can use predicates on nested linked objects.


Not Supported

Certain debug flags exist that can partially accomplish some form of logging, but it is not supported as of 2023.

Parallel Execution

Intra-Operator (Horizontal)

EdgeDB supports parallel execution for sequential scans, joins and aggregations through PostgreSQL's query execution engine.

Query Compilation

Not Supported

EdgeDB compiles queries to SQL and runs it against a stock PostgreSQL so no query compilation is supported.

Query Execution

Tuple-at-a-Time Model

EdgeDB uses PostgreSQL as its query execution engine and so supports the same tuple-at-a-time model as PostgreSQL.

Query Interface

Custom API SQL GraphQL HTTP / REST Command-line / Shell

EdgeQL is the primary interface through which users can query EdgeDB, though GraphQL is also supported. There is driver support for Python, Go, Rust, Dart, Dotnet and JS/TS.

EdgeQL looks to address the object-relational impedance mismatch that occurs between object oriented programs and relational databases. It is a complete SQL replacement (has the same expressive power as SQL). Its salient features are:

  • Easy deep querying: Relations have immutable ids that are used by links to refer to objects. Additionally, attributes are set-valued, so Movie.actors.name can be written cleanly as opposed to requiring multiple joins in SQL. There is no limit on query depth but links must be mentioned explicitly (and not recursively).
  • Designed for programmers: The aforementioned graph relational model and use of of braces { and := for defining structures and assignment operator respectively is similar to most programming languages. Syntax is prioritized over keywords, which enables more legible queries.
  • Strongly typed: EdgeQL has a well-defined type system, unlike SQL which does not have a standard for data types (which has resulted in each DBMS having a unique implementation and a lack of cross-compatibility). Similarly, edge cases like NULL can result in wildly different behaviors with different database vendors in SQL unlike EdgeQL.
  • Composable queries: Unlike SQL, EdgeDB queries are fully composable, i.e. a fragment of a EdgeQL query can be inserted inside a larger EdgeQL expression.

EdgeQL is distinct from ORMs as it is more expressive and always compiles into one SQL query unlike most ORMs which perform multiple queries under the hood (which severely impacts performance).

Storage Architecture


EdgeDB uses PostgreSQL as its backend and storage layer and so has the same disk-oriented storage architecture as PostgreSQL.

Storage Model

N-ary Storage Model (Row/Record)

EdgeDB uses PostgreSQL as its backend and storage layer and so has the same n-ary storage model as PostgreSQL.

Storage Organization


EdgeDB uses PostgreSQL as its backend and storage layer and so has the same storage organization as PostgreSQL.

Stored Procedures


Stored procedures are represented using query aliases. As with object type aliases, these are computed on the fly.

System Architecture


EdgeDB uses PostgreSQL as its backend and storage layer and so has the same system architecture as PostgreSQL.


Virtual Views

Views are referred to as aliases in EdgeDB. An alias is a pointer to a set of values and is computed on the fly whenever the alias is called (hence the support for virtual views).

Aliases are standalone expressions and are thus not limited to object types (tables), but can also be defined for scalars and queries. Object type aliases can also contain shapes that can define additional computed properties or links (e.g. trimmed strings).

People Also Viewed

EdgeDB Logo


Source Code


Tech Docs






Country of Origin


Start Year


Project Type

Commercial, Open Source

Written in

C, Python, Rust

Supported languages

Dart, Go, JavaScript, Python, Rust, TypeScript

Embeds / Uses


Compatible With



Apache v2

People Also Viewed