What would you say is the distinguishing feature of whether something "is a graph database"?
To put it another way, what do the databases you listed have in common with each other that they don't have in common with other NoSQL databases, besides marketing?
A graph database exposes an object model that fits graph terminology: nodes and edges. They (hopefully) are optimized for graph-traversal operations like hopping along a series of edges, which would be painful in a relational model.
In this situation, NoSQL is the marketing term, while a graph database is a clear concept with corresponding performance and capability expectations.
I'm not asking you to explain to me what a graph is.
I've found that it's easier and faster to import and traverse edges in SQLite or PostgreSQL than in some of the systems you listed. I haven't tried RethinkDB but it sounds promising. You use words like "hopefully" and "performance and capability expectations", but distinguishing databases based on their hopes and expectations is not at all a clear concept.
The main difference seems to be whether you call things "nodes and edges" or "documents and references" or "rows and joins" in the documentation.
(edit: removed some negativity, and I'm aware some remains)
The most common and relevant difference is that a graph database has a storage engine that is optimized for graph traversal. For example, in a RDBMS, another row is referenced via a foreign key which involves a lookup to an indexed column, while in a graph database, a node is often referenced by its storage location. This makes graph traversals much cheaper, and is also something that an RDBMS is unable to optimise for because of conflicts with the relational model.
Similarly, the query language is optimised for graph traversal types of queries, in a way that would not be possible in an RDBMS due to the relational model constraints, and also because some of the query operations would be extremely inefficient in an RDBMS storage engine.
> That sounds like graphs but Rethink is not a graph database (compared to Neo4j, GUN, Orient, Arango, etc).
With regards to the listed databases, some are, but the rest are not (and do not claim to be) graph databases.
FWIW, I should mention that I have tried one DB that seems to qualify as a graph database, in that it actually does seem to import and traverse edges efficiently, which is Blazegraph. You tend to have to search past several other things calling themselves graph DBs to find that one.
(But I'm a bit afraid of using it. Any armchair lawyers want to tell me if code that uses a GPL database has to be GPLed itself?)
Yes, "documents and references" and "nodes and edges" is where things become fairly synonymous which is why I asked about RethinkDB supporting relational documents. I honestly think they are doing themselves a disservice by calling it a "JOIN" since that sounds slow and scary. If they wrapped it in a nice API like ".navigate()" or ".traverse()" I think it would be reasonable for them to advertise as a graph database! Tip to anybody at RethinkDB in case they are listening.
