[guodong]

No, not at all! This is a big misunderstanding that implementing high-level graph DBMS query language require BFS/DFS type "traversals", which is another term to use for joins of node records with each other. Systems that adopt these "traversal" algorithms to do joins end up committing to a specific type of joins (what an RDBMS would call an index-nested loop join) and that's usually not very efficient (no matter what those systems might claim). Instead it's better to accept that these are simply joins and use relational join operators that are however optimized for many-to-many joins and cyclic joins (e.g., if you are searching for triangles, etc.). that's what we do in Kùzu. You can read about some of these join algorithms in our CIDR paper (https://cs.uwaterloo.ca/~ssalihog/papers/kuzu-tr.pdf) and some earlier papers (http://www.vldb.org/pvldb/vol12/p1692-mhedhbi.pdf). We have explained what we do always in terms of fast joins and we strongly believe that's the right thing to do for evaluating the graph patterns in a language like cypher! That said, when we move to other computations, e.g., shortest paths, we will be using more specialized graph algorithms as operators as well.

[smartyboi]

Interesting. Part of my pessimism stems from seeing bad graph engines over the decades but perhaps you are here to change exactly that. I will keep track of the latest developments in your git repo. I wish the very best!

[guodong]

Thanks! Yes, we really want to change that situation and think we have some good ideas. If you've used graph databases, we would love to hear and learn from your use cases too, you can reach us at: [e-mail].