Gel joins Vercel

Declarative schema management​

Why do we think it’s acceptable for your database schema to be managed by one ORM library of your backend, which may be multi-language?

• High-level: DDL is nice but let’s be honest: it’s unergonomic and hard to maintain. SQL could totally have a declarative schema, e.g.:

  Copy

  table accounts {
    manager: text;
    company: text;
    contact_email: text;
  
    -- allow only members of the "managers" role to
    -- access rows, and only rows of their accounts
    policy account_managers to managers
        using manager = current_user;
  }

• Migrations: declarative schema requires the database to come with native tooling for schema migrations.

• Language-agnostic: with a declarative schema the database becomes a proper source of truth, the data layout is always defined the same way no matter what programming language you use to interact with it.

Network protocol​

Gel’s protocol is a superset of Postgres protocol, but it’s an entirely different beast:

• Stateless: every request is self-contained (packs the current config and security context) and can be routed to any Postgres server behind the scene.

• Faster: optimized for fewer round trips, data layout is designed to allow clients to cache the coding/decoding pipelines.

• Recoverable: the server communicates extended information about every query to the client. Clients then can make an informed decision about what to do when the network connection breaks or if a transaction needs to be repeated; e.g. if the query is read-only it’s safe to re-establish the connection and re-run the query automatically.

• Babelfish: a single network endpoint can speak HTTP, Postgres’ native protocol, Gel’s native protocol. This removes Postgres’ long connection time problem.

• TLS by default.

Ease of installation and local development​

npx gel init is all you need to install and run a full Gel database instance locally, including Postgres. No sudo needed. Multiple versions of Gel can co-exist and support socket activation to save resources when not in use.

Data model​

We took a big step back and analyzed why the relational model and high level programming languages have a well-known gap between them.

Our insight was that with just one simple adjustment we can elevate the relational model and remove the gap: introduce a notion of "link". Without link tables and explicit joins we renamed "tables" to "object types" and the gap disappeared.

While this adjustment seems small, diverging from the classic relational model instantly put us on an orthogonal path to it. We added multiple inheritance, global unique object identity, polymorphism, and many other concepts. And while we strived to keep our design ergonomic and developer friendly it steepened the learning curve.

Query language​

EdgeQL, the query language of Gel, is like a child of SQL and GraphQL. It’s extremely composable (unlike SQL), set-based (no NULL), and hierarchical (fetch graphs).

The catch? Well, it's a new query language and it's not the ubiquitous SQL.

Creating a new category​

I will never regret building on top of Postgres. It’s wonderful and powerful. It saved us decades of engineering time building a reliable database backend and allowed us to focus on what we thought matters: general ergonomics of relational databases.

But it also put us in a weird category of "how is this different from an ORM". People fixated on looking for similarities between Gel and their favorite ORM without zooming out and realizing the potential of Gel.

Gel’s weird architecture of enveloping Postgres deep within itself didn’t make things easier to explain. Perhaps if we built Gel around our own database engine, or, alternatively, we made Gel an extension to Postgres, things would go differently. But both of these approaches come with their own significant downsides, and even now with hindsight I still can’t tell if they would work any better.

Too much of everything​

Even though we built Gel on top of Postgres, we had to deal with building an entire new database front-end: new data model, advanced migration engine, IO server, CLI tooling, complex and polished client libraries for major languages, UI, EdgeQL and SQL compilers, and many many other things. Adding a full-blown Gel+Postgres cloud did not help with focus either.

When I was raising our seed round, a VC, whom I greatly respect, said to me “you will be boiling the ocean”. This has stuck with me for all these 6 years; there hasn’t been a week of me not thinking about it.

At times we were feeling great: the ocean wasn’t boiling yet, but we could feel the water becoming warmer. But not fast enough. And shipping as much as we did prevented us from focusing on just a few key areas of the product and polish them to perfection.