edgedb VS trustfall

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?

Pleasantly surprised to see Predrag show up as a reviewer, but at the same time not at all surprised:

- The [Firebase technical screen](https://startupandrew.com/posts/how-firebase-interviewed-sof...) would have been much easier with something like this, as it was Just Another Optimization Problem™. Part of me wants to try it again with Picat!

- He's doing other very interesting things with programming languages, e.g.: https://github.com/obi1kenobi/trustfall

Email: [email protected]

Hi, I'm u9g. I'm looking for an internship for either this winter (in a few weeks) or a summer internship!

Some things I've done:

I integrated a [query engine for lints](https://github.com/obi1kenobi/trustfall) (and contributed optimizations) into [OXC](https://github.com/oxc-project/oxc) (a new Rust-based Javascript Linter).

I wrote [several](https://github.com/u9g/money-lens) [toy](https://github.com/u9g/quickquestion/tree/main/extension) languages and syntax highlighting for them.

I also wrote a [js-to-scheme transpiler](https://github.com/u9g/js2scheme/blob/main/example.js).

Happy to work on things compiler or database oriented, but also happy to learn something new!

If you'd like to dig deeper, here are some links:

- cargo-semver-checks: https://github.com/obi1kenobi/cargo-semver-checks

- Trustfall query engine, which powers cargo-semver-checks: https://github.com/obi1kenobi/trustfall

- Trustfall playground, where you can query Rust library APIs in your browser -- for example, "which structs in `itertools` are importable by more than one path": https://play.predr.ag/rustdoc#?f=2&q=*3-Structs-importable-f...

- 10min conference talk on Trustfall: https://www.hytradboi.com/2022/how-to-query-almost-everythin...

I'm also giving a talk at P99 CONF in a few months about how Trustfall's new optimizations API made cargo-semver-checks over 2300x faster: https://twitter.com/PredragGruevski/status/16893002495908003...

No worries!

Trustfall is even more general than semver actually, one can use it to query any data source -- even HN itself:

https://play.predr.ag/HackerNews

Here's a link to that project if you'd like to check it out:

https://github.com/obi1kenobi/trustfall

I gave a 10min conference talk on it last year titled "How to query (almost) everything"

https://www.hytradboi.com/2022/how-to-query-almost-everythin...

I've had my eye on Taxi for a while, and it's neat! I agree that the problems it aims to solve are real and painful in real life.

In my experience, I'm not sure people care about schemas or schema languages — they are just implementation details best left under the hood. This is why in my own work, I started on the query end of the spectrum instead.

This is why I built Trustfall, a query engine able to query any data source: DBs, APIs, files like PDF, CSV, or JSON, or any combination of those.

GitHub: https://github.com/obi1kenobi/trustfall

Playground showing the query "which GitHub/Twitter users comment on HackerNews stories about OpenAI?": https://play.predr.ag/hackernews#?f=1&q=IyBDcm9zcyBBUEkgcXVl...

Here's an example adapter for querying RSS/Atom feeds. Here's an example adapter for querying the HackerNews APIs. Both projects also include a schema and example queries which you can run.