Show HN: EdgeDB 1.0

I have a couple of questions around this.

Firstly, what happens to the performance when I have a sizeable resultset of set-valued data?

I've seen similar ideas implemented in the past that look fine for the Movies and Actors or Books and Authors examples but fall apart badly when you query a number of fields (20+) that have sets within them, which can happen on say, a sizeable reference database of marketing information.

Another question: How deep in the graph can I go, and how much circular reference protection is there? E.g. if I query Movie.actors.movies.actors?

I'm interested in graph databases and data modeling and while it offers some convenience I'm always skeptical but hopeful (mostly from having lost a lot of hours) that these problems have been solved sufficiently to keep performance good in practical use cases.

Q: What are your plans for sharding / scale-out?

At Notion, we run ~480 logical schemas spread across ~32 Postgres databases [1]. Our data model [2] (sorry for the blog post spam) has a recursive / graph-like structures, and we make use of columns or jsonb attributes like `{ table: Table, id: UUID }` which sounds like your polymorphic links feature. It seems like EdgeDB's model lines up well with how we already use our database.

I did a quick cmd-f here, on the linked announcement, and in your docs looking for "shard" and "scale" but didn't find any relevant results. Postgres needs a Vitess!

Q: Do you have plans to support EdgeQL embedding or SQLite?

I am always looking for a way to compile "better than SQL" languages down to SQL. I like Datalog in this area because it's a composable way to define relationships/facts/derivations but no one is putting serious business effort to this idea (honorable mention to logica [3]). EdgeQL also fits the bill -- queries aren't logical, but they are composable -- plus looks easier to teach than most Datalog variants.

I took a peek in the repo and saw that a few EdgeQL components are written in Rust [4]; are you considering porting more logic to Rust? That would make EdgeQL much more embeddable - it could run in WASM or linked into an Android/iOS app. My pie in the sky dream is to use a single composable query/logic language to define all my relations and queries, and then compile that stuff so it works the same on both the client, server DB, and data streams (for incremental materialized views, ideally on both client & server).

If EdgeDB had a Lite version that ran on SQLite, we'd be 66% of the way there.

(To get the materialized view bits on the server, a mad scientist might already be able to point EdgeDB at Materialize [5])

[1]: https://www.notion.so/blog/sharding-postgres-at-notion

[2]: https://www.notion.so/blog/data-model-behind-notion

[3]: https://opensource.googleblog.com/2021/04/logica-organizing-...

[4]: eg https://github.com/edgedb/edgedb/tree/master/edb/edgeql-pars...

[5]: https://materialize.com/docs/overview/architecture/

- The overhead discussed in the docs, which is ~negligible for lots of use case and a perfectly reasonable tradeoff for those.

- The overhead of retries, which with appropriate defensiveness can effectively become an indefinite lock in, but undetected by, the client. When automated by an abstraction layer, this can become pathological pretty easily depending on usage patterns.

The most realistic alternatives are to provide a lower level abstraction (eg “I don’t want your guarantees, I want your errors”), or to provide other isolation options (eg “I don’t want your guarantees, I want my errors”). But there may well be opportunities here because EdgeDB knows as much as it does about the schema, and positions itself as a SQL replacement rather than a companion so it can potentially optimize for at least some of those cases at query time.

That sounds complex enough to boggle my mind, but if y’all are up to it I’ll be excited to see how it goes!