Ask HN: If you've used a graph database, would you use it again?
Interesting question. I think it is critical to point out that, the underlying principles for a graph database is different from RDBMS, because the operators in a graph database may not comply to relational algebra.<p>Consider the following case:<p>Client A issues a query -- starting from a vertex, conduct bounded closure search, giving every visited vertex a mark (coloring, or lexical flag, whatever you would expect from a graph algorithm)<p>Client B issues a query -- clearing any marks applied to a particular vertex, which happens to be one of the visited vertex of Client A&#x27;s query.<p>Now, race condition aside, let&#x27;s assume we first process query A then B. Would we allow query B to succeed? It is clearly possible for query B to break the semantic of query A, for example, query A goes through a bridge and then query B cuts the bridge, so the connectivity information is lost.<p>Of course we could say that such query A should be a part of a transaction, and isolation can be more strictly enforced -- but again, to what degree? Poor locality will cause the transactions to be interconnected with each other. How does a graph database determine what is the true purpose of the algorithm under each query? What does it guarantee?<p>Many graph databases now claims ACID, but what do they really mean?<p>Is it just a fancy query language over a traditional data model? Say, you could also build graph queries for a SQL database -- what does a graph database provide that such graph-over-SQL cannot?<p>p.s. I work on Microsoft Graph Engine: <a href="https:&#x2F;&#x2F;github.com&#x2F;Microsoft&#x2F;GraphEngine" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Microsoft&#x2F;GraphEngine</a>. We decide to build a modular graph processor rather than calling it a graph database, because we don&#x27;t really know by default, what kind of semantics does a user want. With GraphEngine, you could plug in linear query languages likq Gremlin or GraphQL, you can also plug in SPARQL, or traditional relational model with strong guarantees, or down to bare-metal key-value store with atomicity and durability only. I do think that a graph data model is very helpful in many scenarios, but I think we really need to advance the research on the semantic of graph management.