English for Gel (EdgeDB) Developers
Learn the English vocabulary for Gel, the graph-relational database formerly known as EdgeDB: schemas, EdgeQL, and explaining object-oriented queries to a team.
Gel (the database formerly named EdgeDB) presents itself as graph-relational rather than purely relational, and its query language reads much closer to natural object traversal than SQL, so explaining it to a SQL-native team requires vocabulary that bridges both worlds clearly.
Key Vocabulary
Graph-relational — a data model combining the strong typing and constraints of a relational database with the natural, nested object traversal of a graph database, avoiding the joins-everywhere feel of pure SQL. “We’re not writing five joins to get this nested data — Gel is graph-relational, so traversing related objects is expressed directly in the query, closer to how we think about the data.”
EdgeQL — Gel’s native query language, designed to express nested, object-shaped queries naturally, in contrast to SQL’s flatter, table-and-join-oriented syntax. “This query looks nothing like the SQL we’re used to because it’s EdgeQL — it’s built to express nested object shapes directly, without us manually assembling joins.”
Schema-as-code — the practice of defining a database schema in a dedicated schema language and applying it through migrations, treating the schema definition itself as a versioned, reviewable artifact. “We’re not editing tables through a GUI here — the schema is defined as code, reviewed in pull requests just like application logic, and applied through migrations.”
Link — Gel’s schema construct for representing a relationship between object types, roughly analogous to a foreign key but modeled explicitly as a named, first-class relationship rather than an implicit column reference. “This isn’t a bare foreign key column — it’s a named link in the schema, which is why we can traverse it directly in a query without writing an explicit join.”
Computed property — a schema-defined field whose value is derived from an expression over other data, evaluated at query time rather than stored and manually kept in sync. “We don’t need to remember to update this field on every write — it’s a computed property, so its value is always derived fresh at query time.”
Common Phrases
- “Can we express this directly in EdgeQL, or does this really need to be modeled as a raw SQL join?”
- “Is this relationship modeled as a proper link in the schema, or is it just an implicit foreign key column?”
- “Should this be a computed property instead of a field we have to remember to update manually?”
- “Is the schema change actually going through a migration and review, or was this applied directly?”
Example Sentences
Explaining the model to a SQL-native engineer: “Instead of writing three joins to pull an author, their posts, and each post’s tags, this EdgeQL query expresses that whole nested shape directly.”
Discussing a schema design: “Let’s model this relationship as an explicit link rather than a bare identifier column — it makes the schema self-documenting and lets us traverse it naturally in queries.”
Reviewing a migration: “This field should probably be a computed property instead of something the application updates manually — that removes an entire class of sync bugs.”
Professional Tips
- Introduce graph-relational early when pitching Gel to a SQL-only team — leading with “it’s still strongly typed and relational” reduces resistance before showing the more graph-like query syntax.
- Contrast EdgeQL with SQL directly in code review discussions, showing the equivalent joins it replaces — this builds trust faster than asserting it’s “better” without evidence.
- Push for schema-as-code discipline from day one — treating schema changes as reviewable, versioned artifacts avoids the drift that plagues GUI-managed relational databases.
- Recommend computed property over manually maintained derived fields whenever the source data is already in the schema — it eliminates an entire category of stale-data bugs.
Practice Exercise
- Explain to a SQL-native developer how EdgeQL avoids writing multiple explicit joins for nested data.
- Describe the difference between a bare foreign key column and an explicit schema link.
- Write a sentence recommending a computed property instead of a manually maintained derived field.