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).
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.