[dingfeng_quek]

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.

Note: It's different people replying to you.

[rspeer]

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

[jerven]

Don't worry about the GPL part, e.g. see MySQL as a GPL database in wide use.

As long as you access blazegraph via the sparql or tinkerpop interfaces you will clearly be fine.

[dingfeng_quek]

The capabilities and performance of graph databases do differ, and many aren't cheap, nor well known, so if you need one, you'll need to shop around.

Btw, Neo4J is definitely a graph database, although it might not be what you need.