Can edgeDB as "Graph Relational Database" be used for Data Graphs (~Graph Database)?

[D1no]

I'm looking at various developer friendly ways to model features like

• change histories,
• who edited what,
• traversing "a graph"
• when a user is delete, all his data is deleted (GDPR)
• are these two people connected
• audit-ability of tracking changes to data
• etc

this is typically done with graph databases, which are a bit overkill.

So for me is the question: Can EdgeDB as Graph Relational Database be really used for graphs? Since, at the end of the day, it's "just" Postgres SQL under the hood 👀 the reason for this question is sparked by this issue mentioned in the cascading deletes section.

It would be nice to have an idiomatic schema model like EdgeDB implements. I just worry that devs would go crazy on its capabilities (linking) and suddenly hit the ceiling due to the underlying rational database.

Effectively:

• Be able to build models that have "infinite" history (so less CRUD more event sourcing like history objects and specific entities)
• Be able to traverse links between entities.

Thank you for providing your feedback. Also happy to take any coin tosses on other tech / ideas.

---

Other things I am looking at: Dgraph (but they seem to be really wonky on open source, weird feeling about them), using Red Panda (like kafka) event sourcing with MemGraph (kinda talent overkill), going traditional with prisma + extra tech, or turning away from open source and going for something like CosmosDB + tinkerGraph (also talent overkill, gremlin graph language)

[dodyg]

I hope someone answer this question properly. I am curious as well. DGraph is dead unfortunately.

[danformore]

Why is DGraph dead?!

[dodyg]

https://discuss.dgraph.io/t/quitting-dgraph-labs/16702

[janwirth]

for anyone stopping by now: https://archive.is/0523p#selection-649.5-651.1

[D1no]

@elprans would you mind chipping in on my question? Seriously evaluating EdgeDB. Thank you very very much!

[lu-zen]

Did you evaluated ArangoDB? Rock solid document/graph/kv db based on Rocksdb and their query language is very similar to edgeql

[D1no]

I actually lived for a while across their office in Cologne, Germany (back in 2014). To be honest: Typical german start-up that may have good engineering but even the website / touch and feel etc look like garbage. Trying to convince engineers and stakeholders that this is a key technology is not worth the hassle. If ArangoDB professionalizes at some point, has proper community management and doesn’t use times new roman anymore — I may have a look at it again.

I’ll probably stick with a Kafka like event store, materialized views and proper graph DB for graph specific applications. It would still be great to know, where the line is for “graph specific applications” compared to EdgeDB-Postgres (what are the limits of it!?).

[dodyg]

SurrealDB looks interesting although they barely have any drivers at the moment

[D1no]

After almost 4 months I‘d like to bump my OP question again:

What are the limitations of using EdgeDB as a GraphDB?

Thank you.

[gvivster]

Bumping this, because I really want to know the answer as well.

[raddevon]

change histories

You could create a Change type to hold whatever audit data you need — probably a timestamp and a link to an author, at minimum. Then each of your other types could have a multi link changes that could link to each of its changes. This could be implemented on an abstract type (perhaps Auditable) with a changes link that could be extended by all the types you want to be able to audit.

For now, you would have to insert these changes via your application, but the upcoming triggers feature will allow you to do it on the database.

who edited what

The approach described above would also address this.

traversing "a graph"

For a given object, you could traverse its changes:

select ChangeableObject {name, contents, changes: {timestamp, author: {name, email}}}

or you could look at changes and see which objects they apply to:

select Change {timestamp, author: {name, email}, object := .<changes[is Auditable]}

when a user is delete, all his data is deleted (GDPR)

Deletion policies can handle this for you.

are these two people connected

Given this schema:

module default{
    type Person {
        multi link friends -> Person;
        property name -> str;
    };
}

This tells you if the two are directly connected:

with t := (select Person filter .name = <str>$name)
    select Person {name, are_linked := <str>$name in .friends.name or .name in t.friends.name};

To determine connectedness of arbitrary distance, you'd need recursion which we don't currently support but is on our radar. This might be a part of 4.0, but we haven't firmed up the featureset for that version yet.

audit-ability of tracking changes to data

Can you clarify your question here?

etc

I hope this helps, @D1no. Let me know if there's something I've missed or misunderstood.

[D1no]

Thank you for replying. A while ago I went through the tech stack of EdgeDB and concluded that it is an awesome ORM driven relational database, but the fact that PostgresDB is under the hood makes it not a particular well Graph Database. While you can mimic graphs with a relational database, it's just not build for that.

To determine connectedness of arbitrary distance, you'd need recursion which we don't currently support but is on our radar.

This illustrates one of the aspects and even if that is added, handling recursion on the application layer and not on the system layer (i.e. hitting maximum link depths as mentioned in my post) is a performance / memory and data modeling flow that doesn't yield well to what one would consider a "Graph Database".

Story short: I accept your answer but for anybody reading this...

-> calling the Postgres wrapped EdgeDB a Graph Database is much more a investor pitch than a technical foundation. So anybody looking for graph databases (and expects the power of them) should look somewhere else. Otherwise you'll run into regrets.

What EdgeDB is great for however, is for relational database set ups with lots of foreign keys and potential changes in CRUD style applications. So in situations that require "light" graph capabilities.

[elprans]

This illustrates one of the aspects and even if that is added, handling recursion on the application layer and not on the system layer (i.e. hitting maximum link depths as mentioned in my post) is a performance / memory and data modeling flow that doesn't yield well to what one would consider a "Graph Database".

A bit of clarification: EdgeDB is not a classic ORM, i.e. there is no query result post-processing on the "application level" in any case whatsoever. Instead, each EdgeQL query (regardless of its complexity) is always compiled into a single SQL query the results of which are returned to EdgeDB clients directly. Think of EdgeDB not as an ORM but as an alternative frontend to the Postgres query engine.

What @raddevon means above by supporting recursion is adding support for such constructs to EdgeQL. SQL and Postgres support efficient recursive tree and graph traversals via recursive CTEs, but the syntactic ergonomics of those are not perfect. We can do a lot better in EdgeQL.