[jlokier]

You're missing that the documentDB will be faster and simpler to use for some kinds use cases, is simpler to understand in some ways, and that the query/update language used by the documentDB will funnel application design towards storage and access patterns that work better with a documentDB.

Of course you can implement a documentDB on top of a graphDB, or market the latter as the former. And of course there are applications running on a documentDB that would be as fast or faster on a graphDB.

The differences are one of "impedance mismatch" rather than insurmountable differences.

For example, if you query all vertices with a property x=foo, then query all properties of the vertices, and then traverse all tree-child like properties to more vertices, and continue doing this recursively, that query will be like getting all documents with x=foo. But that's more complicated to express in a graphDB QL than a documentDB QL, and likely to run slower on the graphDB (due to data non-locality) if there are many properties or much tree depth.

In general a documentDB stores all the data for a document clustered together without being told to, and likes to retrieve them as a unit. Because that structure is clear, applications tend to be designed around it as an assumption.