EdgeDB is now Gel and Postgres is the future

These days if you want a PostgreSQL based Data Warehouse both Citus and Timescale are extensions/PostgreSQL based databases I would consider before Redshift.

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.

Perhaps. The trouble usually arrives when you need functionality that your specialized database doesn’t have. Then you end up maintaining two databases and spreading your data, business logic, and resources between them. To each their own, though... there are certainly valid use cases for this.

Just wonder what is the advantage of Redshift vs using something such as https://github.com/hydradatabase/columnar, if we are already using postgres?

Postgres is a decent, acceptable _anything_ database.

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).

A lot of the work is now part of MySQL Heatwave, the paid Oracle / cloud edition.

For me, personally, I do a ton of fullstack work in JavaScript-land, but also have Python services for ML-heavy needs, and it’s nice to define one schema that at its root is still SQL while generating query clients for multiple languages.

Addressing your core question: Drizzle is a great ORM with a tastefully designed API—it's clearly a product of love. But it’s still an ORM, and it’s confined by certain design boundaries that come from being a library. For example, what if you want to use TypeScript, Go, and Python on your backend? Do you run three ORMs, each with different APIs? With Gel, you have one data model and a unified querying layer—the true source of truth.

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...

Drizzle still lacks a lot of features / stability (bug fixes required).

Hopefully it improves over time.

Yep. I converted a business from to Postgres in 2004 and never looked back. Stable, reliable, no surprises. Postgres is the answer until proven otherwise.

EdgeQL stays EdgeQL :) I like that name.

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.

> How does this compare to solutions like Supabase.

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! :)

EdgeDB has declarative schemas with baked in migrations and is a clear differentiator. Supports namespaces within a database. EdgeQL improves nested query performance as they are compiled into a single postgres query

> If I have an existing postgres db how hard is it to migrate?

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

You can use access policies [1] to emulate temporal data. See an example in [2]

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

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

We're shipping a slow query log UI in this version to continuously monitor queries in your system.

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.

Good question. We’re indeed similar products.

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.

Just a user here, but I'd say there are many reasons, one of those reasons is in your name: auth.

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.

(article author here)

> 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

In the just released new version we've added SQL support, so now you can use SQL taking full advantage of our data model (access policies, mixins, etc) and the network protocol (automatic recovery on network & transaction error, automatic connection pooling on client/sever).

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.

Yeah, we'll be repairing this shortly. FWIW we're completely revamping our documentation, it's almost a full rewrite, focused on bringing clarity and logic to the navigation, improving search, etc. We should fully wrap it up in a week or two.