Most relational databases are inherently imperative; your schema is represented as a sequence of schema modification commands, usually fragmented across an array of migration scripts. Needless to say, this is not a human-friendly way to represent schema.
In search of more intuitive modeling tools, developers often turn to ORM libraries and NoSQL options, which come with their own tradeoffs.
EdgeDB solves this problem by introducing a first-party declarative schema modeling language that integrates deeply with EdgeDB’s query language, type system, and migration tools.
Schemas consist of object types—analogous to tables in SQL—containing properties and links to other objects. The "link" concept makes foreign key constraints unnecessary.
type User {
required first_name: str;
middle_name: str;
}
No "id" property is required, as EdgeDB automatically generates a unique ID for every object in the database.
EdgeDB's type system was designed from the ground up for consistency and safety. Every piece of data stored by EdgeDB is strongly typed.
str
bool
int{16|32|64}
float{32|64}
bigint
decimal
sequence
datetime
duration
cal::local_datetime
cal::local_date
cal::local_time
uuid
json
enum<X,Y,[...]>
These scalar types underpin EdgeDB's type system, can be used as properties or composed into arrays and tuples. Read the Scalar docs for details, methods, and operators for each type: https://www.edgedb.com/docs/datamodel/scalars/index
EdgeDB introduces the concept of "links" for directly creating connections between objects; this eliminates the need for foreign key constraints.
type User {
required email: str;
}
type BlogPost {
required content: str;
required author: User;
}Modeling a one-to-many relation is simple and intuitive. Under the hood, a foreign key column referencing User will be added to the BlogPost table.
EdgeDB is no toy database. It aims to match or surpass SQL in functionality, expressivity, consistency, and elegance.
module auth {
type User {
# properties...
};
}
module models {
type BlogPost {
author: auth::User;
};
}Schemas can be split up into logical units called modules.
You can choose whether to define your whole schema inside the "default" module or split it into several. If you split it up, use the "{module}::" namespace prefix when referencing the type in other modules.