Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

EdgeDB is now Gel and Postgres is the future

geldata.com

Post reply on HN
Print view View original

111–120 of 126 posts

Re: EdgeDB is now Gel and Postgres is the future

#111

Post by lelanthran »

valenterry wrote: post #108
lelanthran wrote: post #88

Earlier quoted context omitted.

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

First of all, your example constraint is not possible to be statically expressed in SQL anyways. In the typesystem, that is. Sure, you can create a constraint for `'at least one of these two fields must be empty, but both can't be empty'` but that will only be applied at runtime. It's not like any dmbs (to my knowledge) will reject the query at parse-time. Or else, please show me an example of how you would do that.…

> First of all, your example constraint is not possible to be statically expressed in SQL anyways. In the typesystem, that is.

So? The DB will prevent you from violating the constraints, because it cannot tell in advance (i.e. before getting the query with the data in it) whether the data violates the constraint.

> It's not like any dmbs (to my knowledge) will reject the query at parse-time.

What parse-time?

     echo "INSERT INTO tbl_test (c_one, c_two) VALUES (3, 4);
Where's the parse-time in that?

TBH, I am still failing to see your point - this looks like an artificial restriction (the query must be rejected before you present it to the DB).

Whether you call it runtime or compile-time or parse-time, the DB will not let you violate the type safety by accident.

The point is that the DB will enforce the constraints.

> Second, I deliberately said "good programming languages" and you changed that to "mainstream programming language".

Well, if your bar for "good programming languages" rules out all the mainstream languages, what's the point of even discussing your point? The point you are making then becomes irrelevant.

> If all your mainstream programming languages (however you count or define those) don't support that stuff, maybe it's time to move on and choose a better language.

For better or worse, the world has rejected those better languages and relegated them to niche uses. Shrieking shrilly about your favourite languages aren't gonna make them more popular.

You know what's more realistic? Teaching the users of the "poorer" languages that they can get all those benefits of type enforcement in their DB without needing to switch languages.

> In Scala at least, it's trivially possible to define such a constraint with types.

In more than a few languages it's possible to do that. I'm thinking more Prolog, and specific SAT solvers than Scala, though. There's benefits in doing so.

However, the minute you plug an RDBMS into your system, many benefits can be gained without switching languages at all. Like real constraints for XOR or composite uniqueness, referential integrity, NULL-prevention, default values, etc.

Re: EdgeDB is now Gel and Postgres is the future

#112

Post by divan »

1st1 wrote: post #18
keruli wrote: post #15

Earlier quoted context omitted.

Was the rebrand really just for simplicity and clarity? It seems like a lot of work to change the name when it was already a pretty established toolchain, not just for your team, but, and this is more important, for your community. I actually think EdgeDB was a far better name. It actually meant something; yes, it wasn't a pure graph database, but it did work with the general concept of graphs and edges. Gel means no…

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

As someone who has used EdgeDB religiously for years now and still has projects with EdgeQL code generators (that use old syntax), one of my earlier requests was, "Please don't break things". Don't change the syntax of EdgeQL in a backward incompatible way, don't rename commands in the command line, etc. It's really not a big issue to remember some not-so-perfect term. Requiring thousands of people to unlearn/relearn new terms, commands, and names, and rewrite scripts and documents - is an issue. Didn't expect to see the whole name EdgeDB being replaced with another, ungoogleable name.

The argument of "some developers don't look past name and think that it's an edge-computing database" is superficial at best. I can get how it can be annoying, personally, but unless it was backed up with data showing that it hurts adoption, I wouldn't take it as a serious problem worth forcing thousands of users to switch to a new name/commands.

Following this logic, these developers could also ask "MySQL? Huh, you must be running it only on your own servers" or "Gel? Huh, is it some toy database for kids?".

I wish more people realized the enormous cognitive costs and debt created by such renamings. :/

Re: EdgeDB is now Gel and Postgres is the future

#114

Post by gulcin »

DeathArrow wrote: post #80

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

There is something we built for the schema management aspect of Vitess for PostgreSQL.

It is called pgroll, open-source, aiming to minimize potential downtime risks associated with DDL changes, offering multi-schema view, instant rollbacks, and more high-level options like backfilling in batches.

You can check the repo here: https://github.com/xataio/pgroll

Re: EdgeDB is now Gel and Postgres is the future

#115

Post by gulcin »

clarkbw wrote: post #101
dvtkrlbs wrote: post #89

Earlier quoted context omitted.

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.

(neon employee) 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 op…

(xata employee)

I totally agree with schema migrations being painful, have you seen the open-source tool we developed to tackle this problem? It is called pgroll: https://github.com/xataio/pgroll

Any feedback is appreciated!

Re: EdgeDB is now Gel and Postgres is the future

#117

Post by 1st1 »

divan wrote: post #112
1st1 wrote: post #18

Earlier quoted context omitted.

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

As someone who has used EdgeDB religiously for years now and still has projects with EdgeQL code generators (that use old syntax), one of my earlier requests was, "Please don't break things". Don't change the syntax of EdgeQL in a backward incompatible way, don't rename commands in the command line, etc. It's really not a big issue to remember some not-so-perfect term. Requiring thousands of people to unlearn/relearn…

Sorry, divan, for causing pain. This wasn't an easy decision. FWIW we're still strict about backwards compat and all you stuff should continue working.

Re: EdgeDB is now Gel and Postgres is the future

#118

Post by 1st1 »

999900000999 wrote: post #107
1st1 wrote: post #104

Earlier quoted context omitted.

> 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. Currently you have to define your schema in Gel [1] and then write scripts to port your Postgres data into Gel. It's cumbersome, we know, we'll be working on improving the migration flow. > Last question, Supabase heavily pushes the use of Captchas if you use any anonymous auth…

Godot is a game engine. https://godotengine.org Supabase has unofficial support. https://github.com/supabase-community/godot-engine.supabase/... Thanks for responding! I'm about 60% done with my current project so I don't think I'll be up to migrate( again, originally I started with Firebase), but I still definitely consider Gel for future projects. Or if I ever interview with your team( hiring? ) I'll migrate my exi…

> Godot is a game engine. https://godotengine.org

Yeah, I knew that, and precisely because of that I assumed it's a typo :)

We have a native Python client. We can take a look if it works from Godot. Do you know if this is a popular use case?

Re: EdgeDB is now Gel and Postgres is the future

#119

Post by valenterry »

lelanthran wrote: post #111
valenterry wrote: post #108

Earlier quoted context omitted.

First of all, your example constraint is not possible to be statically expressed in SQL anyways. In the typesystem, that is. Sure, you can create a constraint for `'at least one of these two fields must be empty, but both can't be empty'` but that will only be applied at runtime. It's not like any dmbs (to my knowledge) will reject the query at parse-time. Or else, please show me an example of how you would do that.…

> First of all, your example constraint is not possible to be statically expressed in SQL anyways. In the typesystem, that is. So? The DB will prevent you from violating the constraints, because it cannot tell in advance (i.e. before getting the query with the data in it) whether the data violates the constraint. > It's not like any dmbs (to my knowledge) will reject the query at parse-time. What parse-time? echo "IN…

> What parse-time? (...) TBH, I am still failing to see your point

What I tried to say was: in some programming languages, this insert will not even compile. So you don't have to write a test, you don't have to spin up a test database or anything, it just doesn't compile. And I prefer that over having to wait until a query is actually sent before I get an error.

This is relevant for me because 1.) it makes me more productive since I get the error much quicker and I don't have to write a test and 2.) it prevents getting calls in the night because something broke.

I hope that makes it clear.

> However, the minute you plug an RDBMS into your system, many benefits can be gained without switching languages at all.

Yeah, but that doesn't invalidate my original point, does it?

Re: EdgeDB is now Gel and Postgres is the future

#120

Post by lelanthran »

valenterry wrote: post #119
lelanthran wrote: post #111

Earlier quoted context omitted.

> First of all, your example constraint is not possible to be statically expressed in SQL anyways. In the typesystem, that is. So? The DB will prevent you from violating the constraints, because it cannot tell in advance (i.e. before getting the query with the data in it) whether the data violates the constraint. > It's not like any dmbs (to my knowledge) will reject the query at parse-time. What parse-time? echo "IN…

> What parse-time? (...) TBH, I am still failing to see your point What I tried to say was: in some programming languages, this insert will not even compile . So you don't have to write a test, you don't have to spin up a test database or anything, it just doesn't compile. And I prefer that over having to wait until a query is actually sent before I get an error. This is relevant for me because 1.) it makes me more p…

I don't really have time to discuss this in depth, but note that:

1) I still disagree somewhat on the finer points,

and

2) I've upvoted your post anyway because other than the finer points on which I disagree, you make good points anyway.

Cheers :-)

Post reply on HN