edgedb VS pgx

A new DB, with a new query language that's like "SQL done right"? This immediately reminded me of EdgeDB: https://edgedb.com/

Is there anyone here who knows enough about these two products to do a compare/contrast?

The whole thing consists of these main parts:

1. SQL parser: https://github.com/edgedb/edgedb/tree/master/edb/pgsql/parse...

>relational no-sql

Do you mean something like edgeDB?[0]

Or do you mean some non-declarative language completely? I don't see the latter making much sense. The issue with SQL for me is the "natural language" which quickly loses all intended readabilty when you have SELECT col1, col2 FROM (SELECT * FROM ... WHERE 1=0 AND ... which is what edgeDB is trying to solve.

[0]https://edgedb.com/

We need to land #3747, then something like this should work

You have to do your own optimiser to avoid, for instance, the N+1 query problem. (Just Google that, plenty of explanations around.) Many GraphQL frameworks have a “naive” subquery implementation that performs N individual subqueries. You either have to override this for each parent/child pairing, or bolt something on the back to delay all the “SELECT * FROM tbl_subquery WHERE id = ?” operations and convert them into one “… WHERE id IN (…)”. Sounds like a great use of your time.

In the end you might think to yourself “why am I doing this, when my SQL database already has query optimisation?”. And it’s a fair question, you are onto it. Try one of those auto-GraphQL things instead. EdgeDB (https://edgedb.com) does it as we speak, runs atop Postgres. Save yourself the enormous effort if you’re only building a GraphQL API for a single RBDMS, and not as a façade for a cluster of microservices and databases and external requests.

Or just nod to your boss and go back to what being a backend developer has always meant: laboriously building by hand completely ad hoc JSON versions of SQL RBDMS schemas, each terribly unhappy in its own way. In no way does doing it manually but presenting GraphQL deviate from this Sisyphean tradition.

I read in the article that NOT having GraphQL exactly match your DB schema is a best practice. My response is “did a backend developer write this?”

Same idea, yeah. Unfortunately, in our case we couldn't use pytest due to complicated test setup, so we used a customized unittest runner instead.

EdgeDB [1] has indeed a rich GraphQL layer, but it's a very different project.

While it also builds on top of Postgres, EdgeDB replaces the entire relational database front-end. EdgeDB features a SQL replacement language called EdgeQL (analytical capabilities of SQL married with deep-fetching in GraphQL), a higher-level data model (tables -> object types), integrated migrations engine, a custom protocol with great performance & great client APIs, and many other things. Read more here [2].

(disclaimer: I'm EdgeDB co-founder)

[1] https://github.com/edgedb/edgedb

[2] https://www.edgedb.com/blog/edgedb-1-0

I'm curious how this squares up with what someone linked elsewhere: https://github.com/edgedb/edgedb/discussions/3403

> EdgeDB does not treat Postgres as a simple standard SQL store. The opposite is true. To realize the full potential of the graph-relational model and EdgeQL efficiently, we must squeeze every last bit of functionality out of PostgreSQL's implementation of SQL and its schema.

This would seem to be an opposing view of how coupled EdgeDB and PostgreSQL are. Which is it?

It uses pgx (https://github.com/tcdi/pgx) which is our more generalized framework for developing Postgres extensions with Rust.

It's a great question, considering I've been using Rust for a number of years now, and I generally advocate its use for its rich ecosystem, safety and tooling. I actively contribute to pgx, a library for building Postgres extensions in Rust. Yet, Omnigres appears to be all done in C.

Our release today is a framework which extends this functionality to other databases/systems. If you’re familiar with Multicorn[1] or Steampipe[2], then it’s very similar. The framework is written in Rust, using the excellent pgx[3].

We have developed FDWs for Stripe, Firebase, BigQuery, Clickhouse, and Airtable (all in various “pre-release” states). The plan is to focus on the tools we’re using internally while we stabalize the framework.

There’s a lot in the blog post into our goals for this release. It’s early, but one of the things I’m most excited about.

[0] Postgres FDW: [https://www.postgresql.org/docs/current/sql-createforeigndat...

[1] Multicorn: https://multicorn.org/

[2] Steampipe: https://steampipe.io/

[2] pgx: [https://github.com/tcdi/pgx](https://github.com/tcdi/pgx)

BTW one nice easter egg is that with pgx there is actually no reason that we can't build even better search solutions inside the database itself.

> That thread led me to a project/product idea where you take an existing Postgres instance used for normal products or whatever, replicate it to various read only clusters with a custom search extension loaded and some orchestrator sitting on top (I’ve written most of one in rust that uses 0mq to communicate with it’s nodes) and create drop in search from existing databases with a nice guided web gui for automatic tuning suitable for most business use cases.

Very interesting idea -- just want to add one thing, write it in rust (with pgx?[0]) :)

[0]: https://github.com/tcdi/pgx

Hey HN,

It turns out choosing a good database-optimized UUID (and deciding whether to use serial, etc) isn't quite so simple, and I finally got a chance to do some exploration, write about it[0].

One of the reasons Postgres is the best open source database out there is it's extensibility -- so I hacked up a small extension for generating some of the more exotic (but crucially, lexicograhically sortable) UUID generation mechanisms:

https://github.com/t3hmrman/pg_idkit

This idea has been bumbling around my head for a while, but I finally got a chance to build it while working with Supabase on a post about IDs[0]!

Most of the heavy lifting is done by pgx[1] which is an amazing framework for building Postgres extensions in Rust. I think we are very early to the trend of amazing postgres extensions built in Rust, and it's yet another reason that it's an exciting time to be all-in on Postgres.

[0]: https://supabase.com/blog/choosing-a-postgres-primary-key

[1]: https://github.com/tcdi/pgx

[0]: https://supabase.com/blog/choosing-a-postgres-primary-key

The extension is still WIP but for those of ya'll that like Rust it's built on pgx which has excellent DX. The rust involved isn't complicated -- I'm basically laundering the functionality from other crates that are listed in the README.md.

Seems to be using this: https://github.com/tcdi/pgx

- https://github.com/furstenheim/is_jsonb_valid

pgx[0] is going to be pretty revolutionary for the postgres ecosystem I think -- there is so much functionality that can be utilized at the database level and I can't think of a language I want to do it with more than Rust.

[0]: https://github.com/tcdi/pgx