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.
EdgeDB schemas are expressive, concise, and declarative, while maintaining the highest standards of type safety. They consist of object types (analogous to tables in SQL), their properties, and the links between them. The "link" concept entirely abstracts away JOINs and foreign keys.
type User {
required property first_name -> str;
property 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 a high-level "link" concept for defining relations between object types. Links entirely abstract away foreign keys and JOINs.
type User {
required property email -> str;
}
type BlogPost {
required property content -> str;
required link 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. From the outset, we've intended to match or surpass SQL in functionality, expressivity, consistency, and elegance.
module auth {
type User {
# properties...
};
}
module models {
type BlogPost {
link 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.