Live data from Hacker News

EdgeDB is now Gel and Postgres is the future

geldata.com

81–90 of 126 posts

Re: EdgeDB is now Gel and Postgres is the future

#81

> PostgreSQL's query planner/optimizer is decidedly state-of-the-art Postgres's cost-based planner is good, but it's a decidedly 1980s design, predating the famous but also outdated Volcano/Cascades systems (used by Microsoft SQL Server and CockroachDB and others). So much has happened in the field of query optimization in the last 30 years, very little of which has ended up in Postgres, I think. Postgres has gotten…

And JIT is something you would disable, because often it makes queries slower or jus unpredictable (and results are not cached AFAIK).

Re: EdgeDB is now Gel and Postgres is the future

#82
> Arguably, this makes PostgreSQL the only mainsteam database system that is truly open-source. It can't be bought or license-rug-pulled and this creates a kind of trust that can't be emulated in any other way.

SQLite, with far more installations than Postgres, isn't a "mainstream database"?

Re: EdgeDB is now Gel and Postgres is the future

#83

> PostgreSQL's query planner/optimizer is decidedly state-of-the-art Postgres's cost-based planner is good, but it's a decidedly 1980s design, predating the famous but also outdated Volcano/Cascades systems (used by Microsoft SQL Server and CockroachDB and others). So much has happened in the field of query optimization in the last 30 years, very little of which has ended up in Postgres, I think. Postgres has gotten…

The paper seems to mostly focus on the quality of cardinality estimation (mostly driven by statistics) which is admittedly one of the frequent sore points in Postgres. There's been some progress in that area though (CREATE STATISTICS being a highlight).

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.

Re: EdgeDB is now Gel and Postgres is the future

#84
post #72

Figured I'd poke at the quickstart a bit, but the github repo linked to from https://docs.geldata.com/learn/quickstart/setup/nextjs ( https://github.com/geldata/quickstart-nextjs ) appears to be missing.

Fixed. Thank you for reporting this.

https://www.geldata.com/roadmap

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

Re: EdgeDB is now Gel and Postgres is the future

#85
post #82

> Arguably, this makes PostgreSQL the only mainsteam database system that is truly open-source. It can't be bought or license-rug-pulled and this creates a kind of trust that can't be emulated in any other way. SQLite, with far more installations than Postgres, isn't a "mainstream database"?

>> ... mainstream database system ...

> SQLite, with far more installations than Postgres, isn't a "mainstream database"?

It's not a system, it's a monolith library, which is why it is used wherever you want a local database with local storage.

Postgres implementations are a client/server systems even if the connection is on localhost.

It's also MVCC and has RLS and other requirements that do not necessarily apply to a local database like SQLite.

It's not about the number of installations, it's the type of database.

Re: EdgeDB is now Gel and Postgres is the future

#86
post #60

Earlier quoted context omitted.

3 questions. How does this compare to solutions like Supabase. What stands out with Supabase is the sdk support. My current project is probably going to stay on Supabase( it's a hobbyist project regardless), but hypothetically if I was an enterprise prospect how would you pitch your solution. Do you support functions, that I could call from the client for more advanced logic that can't be done with queries ? Why not…

> 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 lang…

Thanks!

I don't know about migrating my current project, but I'll definitely try Gel for a future project.

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

Very very cool.

If I just dump my Supabase project's Postgres DB can I load the SQL into Gel and have everything work. Or would I need to setup the schema.

Ultimately I'm just looking for an open source alternative to firebase-> while amazing, I can't exactly claim to have an open source project that requires a closed source service.

Last question, Supabase heavily pushes the use of Captchas if you use any anonymous authentication. Does Gel also suggest this. Notably Firebase doesn't care, which makes it much easier on end users.

Imagine having to solve a captcha to browse Amazon and add products to your cart, you'd probably just use something else.

Ok, just one more question! How is your SDK support. JavaScript is a given, but Godot support would be nice.

Re: EdgeDB is now Gel and Postgres is the future

#87
post #78
post #56

Earlier quoted context omitted.

> Yes and you absolutely have to. That's not a disadvantage, it's just how it is. Because SQL is the absolute bare minimum. The lowest common standard. And not a great one. Null handling and typesystem for example are way inferior to those of good programming languages. So why would I leave those productivity gains on the table? I think... we're in a agreement? :) EdgeQL doesn't have a NULL (it's a set-based language…

> Most of the time you'll either have grossly inefficient multi-roundtrip query code (hidden from you) Or you spend 5 minutes actually putting some effort in to configuring your ORM. Maybe spend 30 minutes learning if it's your first time. People will spend weeks handwriting SQL to save hours of ORM tuning.

In my experience it is the exact reverse. You spend weeks configuring or tuning your orm calls when you ccould just spend a few hours optimizing your sql. There is a reason most orms has a raw SQL escape hatch.

The sweet spot is typesafe sql libraries. You write your raw sql and library deduces the return type from the database and gives you typesafety (sqlx is really good for this, sqlc for go is similar). It gives you almost all the benefits of ORMs with almost no downsides.

Re: EdgeDB is now Gel and Postgres is the future

#88
post #14

Earlier quoted context omitted.

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…

> Do you run three ORMs, each with different APIs? Yes and you absolutely have to. That's not a disadvantage, it's just how it is. Because SQL is the absolute bare minimum. The lowest common standard. And not a great one. Null handling and typesystem for example are way inferior to those of good programming languages. So why would I leave those productivity gains on the table? Using EdgeQL simple means I have another…

> And not a great one. Null handling and typesystem for example are way inferior to those of good programming languages

There is no mainstream programming language that I know off that offers what are table stakes for an RDBMS.

For example, even trivial SQL things like a constraint saying 'at least one of these two fields must be empty, but both can't be empty' is missing in the "advanced" type systems in mainstream languages.

Re: EdgeDB is now Gel and Postgres is the future

#89

>PostgreSQL seems to be quietly eating the database world. It's not just topping the charts, its adoption momentum is accelerating. Is there something like Vitess for Postgres?

Neon seems to be doing something similar (their hosted solution was not that great last time I checked) most of their stack is open source.

Re: EdgeDB is now Gel and Postgres is the future

#90

> PostgreSQL's query planner/optimizer is decidedly state-of-the-art Postgres's cost-based planner is good, but it's a decidedly 1980s design, predating the famous but also outdated Volcano/Cascades systems (used by Microsoft SQL Server and CockroachDB and others). So much has happened in the field of query optimization in the last 30 years, very little of which has ended up in Postgres, I think. Postgres has gotten…

Also there are now databases purpose built for specific domains. E.g. if you are building a financial ledger I would way rather be interfacing with TigerBeetle than scaffolding an application-driven ledger around Postgres. https://tigerbeetle.com/ . If I am scraping giant amounts of data I would run far away from Postgres for other databases like Amazon Redshift.

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.
Post reply on HN