Live data from Hacker News

EdgeDB is now Gel and Postgres is the future

geldata.com

101–110 of 126 posts

Re: EdgeDB is now Gel and Postgres is the future

#101

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

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

Re: EdgeDB is now Gel and Postgres is the future

#104
post #60

Earlier quoted context omitted.

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

> 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 authentication. Does Gel also suggest this. Notably Firebase doesn't care, which makes it much easier on end users.

We don't have captchas implemented, but when we do, it will be an opt-in configuration option.

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

Golang? We have a great Go client [2].

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

[2] https://github.com/geldata/gel-go

Re: EdgeDB is now Gel and Postgres is the future

#105

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…

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

++

Re: EdgeDB is now Gel and Postgres is the future

#107
post #104

Earlier quoted context omitted.

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

> 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 existing project and document the process.

Re: EdgeDB is now Gel and Postgres is the future

#108

Earlier quoted context omitted.

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

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. (and don't use constraints or indexes, because those only work at runtime)

Second, I deliberately said "good programming languages" and you changed that to "mainstream programming language". You know what? 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.

In Scala at least, it's trivially possible to define such a constraint with types. That ensures that you will never by accident violate that constraint. And that is guaranteed at compile time, so no one is gonna wake you up in the night because your query failed due to that condition you specified.

If you don't believe me, I'm happy to show you the code to encode that logic.

Re: EdgeDB is now Gel and Postgres is the future

#109
post #74

When will Python get a typesafe query builder? Now there is ``` client.query(''' INSERT User { name := $name, dob := $dob } ''', name='Bob', dob=datetime.date(1984, 3, 1)) ``` I'm interested in this and Jetbrains Pycharm and VSCode and CI to catch errors in these. ``` insert(User(name='Bob', dob=datetime.date(1984, 3, 1), children=[User(name='C', dob=datetime.date(2000, 3, 1))]) ```

Probably Python won't get a typesafe query builder until it catches up with its typing to TypeScript. Right now in Python the generics are quite rudimentary, there's no equivalent to TypeScript's keyof or mapped types. We're using all of TS' advanced typing system features to make our query builder work. Python will get a query builder (it's a priority for us now) soon, but it will not be a type safe one. BUT: Python…

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

Re: EdgeDB is now Gel and Postgres is the future

#110

Earlier quoted context omitted.

I ran a 4000qps postgres database set to use no more than 640KB of RAM (its in the configs). The DBA was having fun with my silly idea until Slow-Query takes 10 seconds and we flipped back over to the production systems with much more allowed memory for postgres. My purpose was to show that Linux itself is pretty fast at caching and paging, even if Postgres was hamstrung. The db actually ran fine except for the slow…

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

postgres served 4000qps while restricted to 640 kilobytes of memory.
Post reply on HN