Hacker News Reader

Comment by 1st1 | Hacker News Reader

EdgeDB co-founder and CEO here. Ask me anything.

We are streaming EdgeDB 2.0 launch event right now, join here: https://www.youtube.com/watch?v=1jloGHV31Ow

Congrats on the launch!

How do folks deal with the latency of not being able to run EdgeDB on the same server as their managed Postgres service (e.g. RDS)?

Full disclosure: I work on SpiceDB[0] which is a fine-grained permissions database. SpiceDB can also be backed by Postgres, but we form a distributed cache with our database instances so that trips to the datastore (e.g. Postgres) are avoided at all costs.

[0]: https://github.com/authzed/spicedb

EdgeDB is super efficient in its communication with the postgres backend. Most of the time there's only one roundtrip for any query. So chances are, because of how you can pipeline many operations in EdgeQL into one single query, the latency is still going to be far better than a typical ORM+Postgres combination.

That said, we're working on our cloud, all hands on deck. There you wouldn't have any additional latency.

EdgeDB is looking like a dream db (with batteries included) to me, congrats on the launch!

I wonder if you might wanna join efforts on building your cloud offer with guys at https://neon.tech/ (i'm not affiliated, but I'm waiting for your cloud offering)

We'll be closely looking an Neon and we know the team. There are some related things that we have to figure out before investing time into the integration.

In a recent post here on HN, Shipping Multi-Tenant SaaS Using Postgres Row-Level Security [1], comments indicated gaps in PostgreSQL's RLS implementation, specifically for views (at least until PG15). I suppose EdgeQL is compiled directly to full SQL statements and doesn't utilize views, so this issue in particular may not affect EdgeDB.

Does EdgeDB implement object-level access control on top of PostgreSQL's RLS? Have you run into any tricky edge cases? Did you have any particular inspirations for the design (e.g. Google Zanzibar)?

[1]: https://news.ycombinator.com/item?id=32241820

EdgeDB does not use Postgres RLS, access rules are injected into every query by the query compiler instead. This side-steps the RLS gotchas and limitations (RLS does not allow aggregates in rules, EdgeDB does), but also yields somewhat better query performance.

Have you considered cockroachdb as a backend database? I imagine that although the postgresql emulation of cockroachdb isn't 100% complete, the availability story of cockroachdb is miles ahead of postgresql, so perhaps it might be worth whatever adaptations are necessary.

Alas, we have to wait until CockroachDB becomes a bit more capable SQL-wise. I gave a more elaborate answer in https://github.com/edgedb/edgedb/discussions/3403.

> To realize the full potential of ... EdgeQL efficiently, we must squeeze every last bit of functionality out of PostgreSQL's implementation

> That said, EdgeDB, the implementation, and EdgeQL, the language and the model, are different, and we encourage research into alternative EdgeQL implementations. We'll be releasing the formal EdgeQL spec and the graph-relational model whitepaper to make this easier.

Has the mentioned spec and model whitepaper been released?

Not yet. Our reference documentation is extremely thorough though, an implementor of an alternative backend should be able to use it.

If I have an existing Postgres database (on RDS) can I use EdgeDB to query it? Are there tools to generate a schema from an existing Postgres schema? Or is this mainly for green field projects without an existing database?

EdgeDB is very particular about how the underlying data is organized, so you can't put it in front of an existing database. Importing schemas and data is another story which we're working on.

I asked on Twitter but I'll ask again here :)

What's the current approach for triggers, subscriptions, etc?

Can you perform raw SQL queries through your client or do apps still need to use a separate PG client for that?

Triggers might make it to 3.0, but we'll have to write an RFC and see if it's doable in the timeframe we have for it and given the other higher priority items on the ToDo list. We contemplated mentioning them in the 2.0 blog post but decided not to over-promise :)

Regarding subscriptions -- polling is the current best (and unfortunate) answer. We'll keep researching this area.

> Can you perform raw SQL queries through your client or do apps still need to use a separate PG client for that?

Not yet. We plan to eventually allow read-only SQL queries to go through EdgeDB for plugging existing analytical tools/BI. But the demand from the community for this feature has been so far pretty low.

> Not yet. We plan to eventually allow read-only SQL queries to go through EdgeDB for plugging existing analytical tools/BI. But the demand from the community for this feature has been so far pretty low.

It's interesting you say this. This is the reason I passed on EdgeDB. If it was additive to SQL (you can use EdgeDB optionally) that would be great. Im not sure people would ask for it, but given the option everyone would use it.

> But the demand from the community for this feature has been so far pretty low.

Makes sense since most read queries can (probably) be performed already with EdgeDB.

But my point about executing raw SQL was regarding having an escape hatch for features like listen/notify, etc.

I guess the solution is that for now apps will need a second PG client. Do you anticipate any problems with that approach?

Where can I find instructions on how to build EdgeDB from source? Also, what is the difference between https://github.com/edgedb/edgedb and https://github.com/edgedb/edgedb-cli?

Build instructions: https://www.edgedb.com/docs/guides/contributing

Repos: the first repo is the database itself; the second is our CLI -- tools for migrations, dump/restore, repl, etc.

congrats on this milestone.

I’m currently using a graph database (dgraph) mostly so I can easily query complex relationships), and I’m wondering whether EdgeDB has similar performance due to how it stores data?

my understanding of EdgeDb is that it stores everything in a single table, and there’s an underlying graph structure. does this give added performance on complex queries?in other words, does EdgeDB perform complex queries involving multiple relationships better than an equivalent complex Postgres JOIN query? how does the performance compare to the average graph database for queries involving complex relationships? has it been performance tested on complex queries?

EdgeDB stores data in a fairly normalized table layout, where every object type corresponds to a physical table.

The performance of deep hierarchical queries with EdgeQL will be better than SQL with joins because with joins you'd have an unnecessarily wide denormalized set of rows. EdgeDB instead aggregates data in nested arrays via subqueries. The performance is great.

https://github.com/edgedb/imdbench

thanks!

For the rust client, is there any plan to introduce a query builder and/or generated typing? Currently it feels very sqlx like which is ok for some, but I prefer to have a bit of typing.

Yes, we want to have query builders for all languages. If you love Rust and have time to contribute we'd love some help. Figuring out a great QB Rust API might take some time.

Will edgedb ever launch frontend querying with JWTs like Supabase, Hasura, Fauna?

Yes, we're building that capability. With 2.0 we made our protocol stateless and can tunnel it through HTTP now, allowing access to full APIs of our clients. (Although EdgeDB also exposes a REST endpoint that you can access with any HTTP client from any language).

We'll be working on tightening and adding the necessary security mechanisms to allow exposing the DB directly to web in 3.0 and onward.

This would be great. I'm a big fan of Hasura and not having to write crud apis. But would prefer having more or less the same query language on all clients.

Yeah, that's the dream. But there are lots of tiny details to figure out to make it really usable in prod and not gimmicky. Hasura is a great product indeed.

We're still working out the kinks, but some form of this will definitely be possible.

You can already hack this by defining access policies and writing an EdgeQL proxy server that authenticates incoming requests, sets the appropriate global, and forwards the query to the database. There's a Python/Flask implementation of this pattern here[0].

We also have a JavaScript example app demonstrating access policies to simplify authorization logic using Next.js/getServerSideProps[1] and a user management platform you may have heard of called Clerk[2] :)

[0] https://github.com/edgedb/edgedb-examples/tree/main/flask-pr...

[1] https://github.com/edgedb/edgedb-examples/blob/main/nextjs-a...

[2] https://clerk.dev/

EdgeQL is very nice. Will there be a Haskell client in the no-so-distant future?

General client question: Which ones do you intend to officially support? Interested in Elixir client that is now community maintained.

https://www.edgedb.com/roadmap#client-language-bindings

According to the roadmap:

  - Python, Javascript/Typescript, HTTP are done

  - Go, Rust, Ruby, Java, and .NET are planned

Looks like it hasn't been updated now that Rust is out. But seems like those are the languages planned.

We already have a Go driver as well[0] and you can get pretty far by executing queries over HTTP[1] though that's not as capable as a full client. As you said, the roadmap needs some freshening up.

[0] https://github.com/edgedb/edgedb-go

[1] https://www.edgedb.com/docs/clients/http/index#edgeql-over-h...

Plans for mapping/postgis?

Yes, we'll have it. We need to implement proper extension system to be able to integrate GPL-licensed extensions. On our todo.

Reply on news.ycombinator.com