EdgeDB is now Gel and Postgres is the future

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.

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.

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

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

TigerBeetle is impressive, but correct me if I'm wrong the schema can't be changed. To me, that that's like a single use DB, when often people don't know what they need.

Which is arguably the most important part of a planner. If you don't have good cardinality information, it doesn't matter if you have fancy planner strategies. They'll be employed in the wrong situation, and won't produce the good plans we all want.

MySQL hasn’t had nearly as many innovations. That said, for a long time, it was often faster for simpler queries, and especially range queries, IFF your schema was designed to exploit the fact that it’s a clustering index, so rows are physically located next to the PK. If you’re using UUIDv4 PKs, you’re throwing away its entire advantage, and Postgres will almost certainly be faster.

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.

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

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

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.

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.

No offense, but 4000 QPS is not large. I ran a 100K+ QPS MySQL instance with 384 GiB of RAM.

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

Not using SQL makes it basically a complete non-starter for any business unless it had some extremely compelling niche feature that you absolutely need and can't be found elsewhere. SQL has a massive ecosystem around it. All the examples I see are either some bespoke typescript library, or treat queries as strings. Obviously it can't hook into any of the zillion query builder libraries out there, and you'd have to go implement one or write a decent amount of code for an existing one to be able to use it. I also don't see any docs for JVM usage at all, which is like half the industry.

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.

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

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.

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

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

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.

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.

Not in the immediate future, but we have a member in our community who's building something. We'll see if they get near the finishing line.

Can we add filters and subqueries to query, like we do with an orm?