This kind of work is a major step. The big disadvantage of a graph database is arbitrary graph modeling of data/shoehorning data into a graph model, and an inability to derive information that isn’t itself a graph.
Please explain a bit further what you mean with arbitrary graph modeling? From experience, I find graph models a good natural fit for entity-relational data, whereas traditional relational models start to feel arbitrary and burdensome.
Many graph databases can aggregate on nodes and edges much easier than in RDBs, so I don’t really buy your second point either.
First cut, I'll edit later because I had to drop my pursuit of graphs a few years ago and paging cache back in:
When I had to build a little special graph system, it was because I wanted to traverse a given graph and, given a set of detail subgraphs return a set of node pairs of type A and B and an edge A->B in which:
* Each node of type A and of type B was a group-by of a small set of patterns of source data nodes. Because each query filters the source data nodes differently, these synthesized A and B nodes are query-specific. A query might return any number of pairs based on the data and the filters.
* Each node of type A and node of type B had as its name the value of a specific attribute shared by subgraph elements (node name was a group-by) and contains attributes that were counts and sums of attributes of the subgraph elements.
* The edge between each A -> B pair was itself an aggregation of patterns of nodes that connected between certain detailed elements collected by A and certain detailed elements collected by B, with attributes related to the count of patterns connecting the A and B nodes.
I was unable at that time to locate a system that allowed queries that aggregate patterns via node constructors and edge constructors.
One of the arbitrary choices in the modeling is when to create an edge and when to perform a retrieval by seach with attribute filters. Realistic systems seem to use a mix of both- why? Now I need to keep in mind the difference between reaching a vertex via edge with the correct labeling/attributes and just reading via an index. And which aspects of things like transaction attributes are attributes and which things need an edge traversal to reach. Being unable to define edges from an edge in some systems is silly. Who says the set of things connected by edges cannot include edges? Some graph systems allow this, others don't. That's arbitrary. It means edge can't therefore aggregate anything via edge relationships.
And, simple things like return count of nodes and sum of particular attribute values grouped by attributes, where the nodes and edges meet some criteria, wasn't available. The systems imposed a need to return nodes and edges. Nothing in set theory or graph theories prevent math from being performed on a graph and reasoning based on the math, and I don't want the database preventing it either.
I'm sure I haven't kept up with the latest developments. Query-specific synthesizing of graph constructs and non-graph data together are probably my main issues, and the DB that makes those convenient is of somewhat more interest.
Sounds like that particular use-case is not a good fit for any existing database. You may want to look at raw n-quad stores like Badger and write your own meta-graph query engine on top of that.
I'm sure there's got to be more to it than this. The intro was too obviously mapable to a relational database using foreign keys and associative tables. Look forward to a post getting deeper into EdgeQL.
Most of the "killer features" are in EdgeQL, SDL, and the tooling surrounding EdgeDB. But the goal of this post is just to describe the graph-relational model of data persistence at a high-level—how graph-relational databases "think" about data. We intentionally defined the term in a way such that it isn't strongly coupled to EdgeDB — EdgeDB is just one possible implementation of the model. And there's a lot more to EdgeDB beyond that fact that it's graph-relational.
