[controversy]

Let’s play make a Facebook. You need profile information. That’s information that’s access as block. We can use documents for that. We then want to track relationships. Friends. Friends of friends. We can use a graph. We might need a lightweight cache. Opaque entries accessed by key. We can use a key value store for that. ArangoDB does all of theses. Some times you want to join documents to documents or any other form of pairing. ArangoDB does that too.

You can then scale this across multiple machines as necessary. The benefit of such a design is that your team only needs to learn on technology not many. You don’t need to know redis, postgres and Neo4j to derive the same benefits.

[zaphirplane]

Isn’t a graph dB a super set of a document dB Node == document Properties = attributes Edge == relationship

[jlokier]

At a high level, you could say that you can model your data in either, so either can implement the other, and you can also include relational DBs in that too. They are all "equivalent" in an abstract sense. But it doesn't mean they support all uses equally well.

A graph DB is optimised for a traversing a general graph structure, whereas a document DB is optimised for a tree-structured document and sometimes queries can't traverse links between documents.

Optimised means performance, layout in storage (so locality, retrival and join patterns), the kinds of query operators that are offered, and even that the language they use is more suited to different ways of modelling data.