EdgeDB is now Gel and Postgres is the future

One notable exception for MySQL is INSTANT DDL in 8.x, thanks to contributions from Tencent, which is an extremely nice QoL upgrade that Postgres doesn’t have. The other is logical replication, something Postgres does support now (and has for several years), but didn’t for a long time.

Bisecant fractal databases like HyperKlingonDB are excellent at storing bisecant fractal data, but terrible at anything else (often, just plain terrible overall due to being immature).

But even in the 9.4 days (~a decade ago) I was pushing Terabytes worth of analytics data daily through a manually managed Postgres cluster with a team of <=5 (so not that difficult). Since then there have been numerous improvements which make scaling beyond this level even easier (parallel query execution, better predicate push down by the query planner, and declarative partitioning to name a few). Throw something like Citus (extension) into the mix for easy access to clustering and (nearly) transparent table sharding and you can go quite far without reaching for specialized data storage solutions.

We have a blog post about that and more [1].

---

By the way, if you visit Drizzle’s website, you’ll see that Gel is one of their biggest sponsors. We worked closely with Drizzle to ship a first-class integration with Gel. You can use Gel’s schema and migrations, and Drizzle will just work. You can even use the Drizzle query builder and EdgeQL side by side if you want.

[1] https://www.geldata.com/blog/a-solution-to-the-sql-vs-orm-di...

Hopefully it improves over time.

This is all subjective, of course, but I wouldn’t call 100K QPS large, either. It’s getting on the high end of what you might reasonably want to handle without horizontal scaling, but it’s still not “large.”

If you want to experiment with syntax for database queries, macros that translate to SQL at compile time seem like a much better way to get traction, but pretty much everything I've seen ends up being a more verbose cosmetic variation of SQL. The one big flaw to fix is that SELECT should have been at the end.

GelDB's auth is versatile and doesn't cost a dime, while Supabase auth is only free up until 50,000 monthly active users, then it costs $0.00325 per MAU (> 100k MAU).

I personally just love its query language and the typescript query builder.

Gel is somewhat similar to Supabase on the surface—both run on Postgres, both have Auth, and both offer AI features, a CLI, and a UI, among other similarities.

However, there’s a big difference beneath the surface: Gel comes with a high-level data model (abstract types, mixins, access policies) that replaces tables and joins. It’s still relational (and we’re about to publish a paper on that), but it’s more high level, strict, and yet more flexible.

On top of that, we have a built-in migration system (where schema is a first-class citizen), a performance-tuned network protocol, and a query language called EdgeQL, which is like a child of SQL and GraphQL. These are just a few of our “deep” features.

All in all, Gel is a fresh take on day-to-day database development. We cut no corners in trying to push the core database developer experience forward.

We'll continue bridging the gap to make it easier for companies to adopt Gel for an existing database. We either will invest in creating a tool for migration, or maybe some more exciting options we're currently pondering on.

> If I use some other extension like timescale is that compatible with gel [...] Postgres is so powerful partly because of its ecosystem, so I want to know how much of that ecosystem is still useable if I’m using gel on top of Postgres

Playing nice with the ecosystem is the goal. We started off with more of a walled garden, but with 6.0 a lot of those walls came down with direct SQL support and support for standalone extensions [1]. There is a blog post coming about this specifically tomorrow (I think).

> And is there a story for replication

Replication/failover works out of the box.

> subscribing to queries for real time updates?

Working on it.

> so can I add gel to an existing Postgres instance and get the benefits of the nicer query language or does it rely on special tables?

Gel is built around its schema, so you will need to import your SQL schema. After that you can query things with EdgeQL (or SQL/ORM as before).

[1] https://github.com/geldata/gel-postgis

I also liked EdgeDB (I'm biased, I coined that name myself). But at every conference we had the same conversation with developers:

"EdgeDB? Huh, must be an edge-computing database. Are you running SQLite?"

There are other minor reasons for the rename, but this annoyance persisted for a number of years and we decided to pull the plug on it.

> I've been a true evangelist for EdgeDB over the last two years

Thank you. This means a lot.

Our users do get performance issues, usually because they start really using our data model to its full potential, creating tens / hundreds complex access policies, 100-lines long EdgeQL queries etc. We have EXPLAIN command to deal with, and we also support our customers directly helping them understand and fix their system. All of the findings trickle down to the core product so that the rest can benefit too.

Supabase is great and works well if you want vanilla (more or less) Postgres with some integrations ready to go.

With Gel you get a Postgres with a data layer on top. If you want to have a data model with abstract types & mixins that's easy to work with and scale in complexity, advanced access control, built-in migrations schema engine, hierarchical graph query language on top of SQL, more robust client libraries -- that's Gel.

Gel is opinionated and vertically integrated and that's it's core strength. All of its components were developed in tandem -- from the network protocol to client APIs, from the EdgeQL query language to the data model to the migrations engine and so forth. It provides more cohesive experience and can give you non-trivial performance and DX gains if you commit to it.

> but hypothetically if I was an enterprise prospect how would you pitch your solution.

Total TypeSafety enforced at all levels, built-in migrations engine, best in class access control (we'll be blogging about our access control vs RLS soon.)

> Do you support functions, that I could call from the client for more advanced logic that can't be done with queries ?

With Gel 6 we'll be announcing the new `net` module tomorrow (spoiler!). You'll be able to schedule HTTP calls from triggers/queries/functions.

> Why not brand as GelDB. Would probably be easier to Google. Plus it tells me instantly what your selling.

Well, rebranding from Gel to GelDB would be just a text change to the homepage, so hypothetically the door is open for that. But I hope we can make Gel work, just the same way it works for Render/Neon/Fly.

> PS: Can you offer something like a hobbyist tier for 10$ a month.

Stay tuned, we'll announce some news on that in a couple of days! :)

[1] https://docs.geldata.com/reference/datamodel/access_policies

[2] https://github.com/geldata/gel/issues/4228#issuecomment-1208...

The main hurdle would to migrate the schema. You'll have to define your schema in Gel (take a look at the reference here [1]) and write a script to copy your data.

We are discussing internally how we can simplify this process, this is becoming a popular question.

> Can I write regular joins if I need to?

You can use EdgeQL and SQL side by side now though one connection in the same function. Gel's schema is still relational (even though it's more powerful with features like multiple inheritance).

This page describes the details [2] of how SQL works with our schema (spoiler: it's very straightforward and no different from a hardcoded SQL schema).

> Do you have plans or do you already support db branching ?

We call Postgres databases "branches" in Gel. And we have tooling around them [3] to have git-like experience with them. Conceptually you can map (manually) your Gel branches to your Git branches if you wish.

[1] https://docs.geldata.com/reference/datamodel

[2] https://docs.geldata.com/reference/reference/sql_adapter#que...

[3] https://docs.geldata.com/reference/cli/gel_branch

Was linked from one of your articles, returns 404 for me.

there isn't something like Vitess for Postgres yet but there needs to be. Migrations are painful in general and they become very painful at scale. i haven't used gel yet, i know it manages migrations but i don't know to what extent. most of my experience is with prisma, drizzle, and atlas.

neon is working on some plans to solve migrations at scale. we think our custom storage layer will allow us to optimize certain paths, like setting a default value in a new column for a table with millions of rows. this alter command can take a lock on a table for hours. but ultimately we need better tooling.

ideally there is a client and a hosted service such that you can use the client to run migrations on your own from the CLI and integrate it into your dev workflow. the hosted service version allows you to push up your schema change from the client to an API. from there you can manage the migration rollout from an operational dashboard that helps you tune resourcing.

when i was at github we used vitess to roll out a migration that took 3 weeks to complete. a long time to wait but that's a better tradeoff compared to a migration that takes down production for 6 hours.

[1] https://docs.geldata.com/reference/reference/environment#gel...