Despite being fundamentally different technologies, EdgeDB and GraphQL solve some of the same problems. GraphQL is a specification for implementing typesafe APIs, consisting of a data modeling language, a query language, and a set of associated tools. EdgeDB is a database, coupled with an associated data modeling language, a query language (EdgeQL), and set of associated tools.
Indeed GraphQL was a source of inspiration for the design of EdgeDB, specifically:
So below we compare GraphQL and EdgeDB side-by-side. If you're familiar with GraphQL, this should be an effective way to map syntax and concepts you're already familiar with from GraphQL onto EdgeDB. Moreover, the examples below will highlight scenarios where GraphQL falls short relative to a fully-fledged query language like EdgeQL.
Both EdgeDB and GraphQL provide a schema definition language (SDL) for defining your schema. In the case of GraphQL it's your API schema; in the case of EdgeDB it's your application's data model. Let's see how these two SDLs stack up side-by-side.
# No native support for
# temporal or JSON fields
String
Boolean
Int
Float
IDstr
bool
int{16|32|64}
float{32|64}
uuid
bigint
decimal
sequence
datetime
duration
cal::local_datetime
cal::local_date
cal::local_time
json
By virtue of being a database instead of an API definition language, EdgeDB's SDL is far broader in scope than GraphQL, to include concepts like constraints, default values, computable properties/links, indexes, stored procedures, link properties, and much more. Check out the Data Modeling showcase for a more complete picture of EdgeDB's data modeling capabilities.
GraphQL and EdgeDB both feature an associated query language. To facilitate side-by-side comparison, we'll be considering a hypothetical GraphQL API that supports querying and mutation of your entire database.
In fact, this isn't just a hypothetical; EdgeDB instances can process EdgeQL queries! With the flip of a switch, you can query and mutate data in EdgeDB via GraphQL. For details, check out the GraphQL showcase page and documentation.
All queries in the following sections assume the following schema:
abstract type Person {
required property name -> str {
constraint exclusive;
};
}
type Villain extending Person {
link nemesis -> Hero;
}
type Hero extending Person {
property secret_identity -> str;
property number_of_movies -> int64;
multi link villains := .<nemesis[IS Villain];
}query getHeroes {
Hero {
id
name
secret_identity
}
}SELECT Hero {
id,
name,
secret_identity
}mutation {
insert_Hero(data: {
name: "The Falcon",
secret_identity: "Sam Wilson"
}) { id }
}INSERT Hero {
name := 'The Falcon',
secret_identity := 'Sam Wilson'
};The examples above draw comparisons between GraphQL and EdgeDB where possible. However, due to the fundamentally different nature of the technologies, there is a wide swath of EdgeDB features that are out of scope for an API specification language like GraphQL: computable properties, subqueries, with clauses, type casting, and a large set of built-in operators and utility functions. For a more comprehensive overview of EdgeDB features and syntax check out the EdgeQL showcase.
