[pphysch]

Graph query languages like Cypher are great, but I am wholly unconvinced by the concept of a dedicated, general-purpose "graph database".

IMO, you're better off just using Postgres/etc, modeling your graph data there, and pulling in subsets of your graph for in-memory analysis. This is for the 99% of enterprises that aren't doing online streaming graph analysis on TB-scale graphs, and the other 1% should probably figure out something tailored* to their specific business model.

* Graph algorithms are more accessible than ever with GenAI code, and efficiently modeling a graph in memory is trivial (it's just structs with pointers to other edges/nodes, plus its nice to have full control over the memory layout).

[adsharma]

Just use postgres (or another SQL db) ignores the following innovations:

* Columnar storage * Compressed Sparse Row on disk * Factorized joins * ASP joins, WCO Joins

Details: https://vldb.org/cidrdb/2023/kuzu-graph-database-management-...

[pphysch]

I'm not saying "only use Postgres", but you need to explain why core graph data needs your listed features.

[reaanb2]

We had general-purpose graph databases before graph databases became a thing. I'm talking about relational databases. Values are the vertices, tuples are the edges, FK constraints are inclusion dependencies. In fact, n-ary relations means a hypergraph database, not just a binary graph db.

[adsharma]

Many recent graph databases are built like this. If you compare ladybugdb vs duckdb, the internals are very similar.

The main innovation is the "REL table". You can think of it as a many-to-many relationship table on steroids with optimizations at the storage layer and join algorithms.

Definition of what makes something a graph database (apart from the query language) is contested. But we seem to be moving towards: build a reasonable relational database and then add a "REL table" to it with join optimizations.