[fermisea]

I'm building https://www.ergodic.ai - and we are using a graphs as the primary objects in which the intelligence operates.

I don't think every graph needs a graph database. For 99% of use-cases a relational database is the preferred solution to store a graph: provided that we have objects and ways to link objects, we're good to go. The advantages of graph dbs are in running more complex graph algorithms whenever that is required (transversal, etc) which is more efficient than "hacking it" with recursive queries in a relational db.

For us, I've yet to find the need for a dedicated graph db with few exceptions, and in those exceptions https://kuzudb.com/ was the perfect solution.

[refset]

> which is more efficient than "hacking it" with recursive queries in a relational db

It seems to me that the way recursive CTEs were originally defined is the biggest reason that relational databases haven't been more successful with users who need to run serious graph workloads - in Frank McSherry's words:

> As it turns out, WTIH RECURSIVE has a bevy of limitations and mysterious semantics (four pages of limitations in the version of the standard I have, and I still haven't found the semantics yet). I certainly cannot enumerate, or even understand the full list [...] There are so many things I don't understand here.

https://github.com/frankmcsherry/blog/blob/master/posts/2022...

[monero-xmr]

> For 99% of use-cases a relational database is the preferred solution…

After enough years you realize this is the case for every single problem

[fermisea]

"After trillions spent in GPUs and data centers, the AI gold rush was finally over when a developer in Lithuania built the pg_thinking plugin - turns out postgres was all you needed all along."

[bttf]

would you consider needing to do community detection as a reason for using graph over relational?