Re:Grafeo – A fast, lean, embeddable graph database built in...
by justonceokay on Saturday March 21, 2026 @12:41PM
(#47468614)
Yes a graph database will happily lead you down a n^3 (or worse!) path when trying to query for a single relation if you are not wise about your indexes, etc.
[ Parent
| on HN ]
Re:Grafeo – A fast, lean, embeddable graph database built in...
by cluckindan on Saturday March 21, 2026 @02:15PM
(#47469673)
That sounds like a ”graph” DB which implements edges as separate tables, like building a graph in a standard SQL RDB.
If you wish to avoid that particular caveat, look for a graph DB which materializes edges within vertices/nodes. The obvious caveat there is that the edges are not normalized, which may or may not be an issue for your particulat application.
Re:Grafeo – A fast, lean, embeddable graph database built in...
by adsharma on Saturday March 21, 2026 @12:48PM
(#47468701)
Are you talking about the query plan for scanning the rel table? Kuzu used a hash index and a join.
Trying to make it optional.
Try
explain match (a)-[b]->(c) return a.rowid, b.rowid, c.rowid;