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

71–80 of 126 posts

Re: EdgeDB is now Gel and Postgres is the future

#71

Post by re-thc »

paulryanrogers wrote: post #23
atombender wrote: post #19

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

How does MySQL compare? I get the sense that innovations land there sooner because of all the mega corps that use it.

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

Re: EdgeDB is now Gel and Postgres is the future

#73

Post by 1st1 »

the_duke wrote: post #68

Lesson: if you start a new database company, start with SQL. Almost every DB that starts without SQL support eventually ends up adding it back in later.

True. In our case it's not that simple. By resisting adding SQL early on we were able to advance our data model & schema without SQL holding us back. And now we've added SQL in such a way that it takes full advantage of our stack.

Re: EdgeDB is now Gel and Postgres is the future

#74

Post by 1st1 »

aitchnyu wrote: post #63

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, and all other languages that we support, can use codegen.

Just put your query in a `.edgeql` file, and run a special command. Gel will generate a fully typed function that runs that query.

Re: EdgeDB is now Gel and Postgres is the future

#76

Post by 1st1 »

krashidov wrote: post #70
1st1 wrote: post #3

Co-founder here - AMA.

If I have an existing postgres db how hard is it to migrate? Can I write regular joins if I need to? Do you have plans or do you already support db branching ?

> 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

Re: EdgeDB is now Gel and Postgres is the future

#77

Post by lmm »

the_duke wrote: post #68

Lesson: if you start a new database company, start with SQL. Almost every DB that starts without SQL support eventually ends up adding it back in later.

That's like saying you should start with microservices/kubernetes/etc. because every company ends up needing those things. IMO you should delay adding SQL as long as possible so that it doesn't compromise your design.

Re: EdgeDB is now Gel and Postgres is the future

#78

Post by lmm »

1st1 wrote: post #56
valenterry wrote: post #53

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…

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

Post reply on HN