Performance Comparison Between ArangoDB, MongoDB, Neo4j and OrientDB

>Additional features like documents and deep indexes are nice of course but can be (and often are) implemented using relational databases as well, so in the end there really isn't such a large advantage to be gained from using a graph database, especially when taking into account the immaturity of many solutions in that space.

I've worked with graph data stored in rdbms in the medical informatics space. As you say, there are ways to correctly handle complex graph data in rdbms.

I've also used neo4j as the backend for a wall street analytics app that's in production. Could it have been done in rdms? Sure, but the ad hoc queries that needed to be run against the data were much easier to express as graph traversals than SQL.

There are some obvious downsides with using a graph database, mainly that it's practically impossible to find programmers with non trivial production experience, but it's been a great fit at the two startups I used it at since I got to implement it from the ground up and didn't need a large team.

That being said, database pragmatism is the main lesson to be learned here. Use the right tool(s) for the right jobs.

(Disclaimer: Max from ArangoDB here) I am all for database pragmatism. Fortunately, the choice "graph database" or "non-graph database" is no longer binary. We at ArangoDB are convinced that graphs in data modelling have their merits (namely when you need "graphy" queries), but you do not want to be locked in to the graph data model. Therefore we argue for multi-model databases, which can give you graphs, but do not force you to use graphs for all and everything. With "graphy" I mean queries that involve paths in a graph whose length is not a priori known (e.g. ShortestPath).

Rant warning:

After working with Neo4j for about six months I would definitely NOT recommend it to anyone. In my experience it has been the least reliable and most buggy database solution I've ever worked with.

From the engineering point of view it has a host of core issues that make it really hard to write code, such as constant deadlock exceptions. These are caused by the fact that the database is largely incapable of handling two simultaneous upserts if those upserts touch the same node. Where most mature, decent DBs can handle this completely transparently Neo4j just panics and returns an error. This means writing Neo4j queries ends up requiring tons of boilerplate to wait for exclusive locks on nodes and/or retry upserts until they succeed.

From the devops perspective managing a cluster is also extremely painful, as there are frequent issues with replicas getting behind on syncing due to the server's pathetically slow write performance even with SSD storage volumes. We tried everything but the bottleneck was the server processes themselves, not the storage volumes, network connection, CPU, etc. We threw some really nice hardware at our Neo4j cluster but it still struggled to keep up with write loads in the range of 500-2000 writes per minute.

The final straw was their latest version 2.2 which they were advertising as a massive improvement in speed and reliability. When we upgraded it turned out to be the exact opposite. A few of our queries got faster but overall most of them got an order of magnitude slower. Their support basically told us that we'd need to rewrite many of our queries or manually set a flag to use their older query engine (and therefore miss out on the speed of the new query engine). Needless to say we decided if we needed to rewrite queries we were going to rewrite them to use a different storage engine entirely.

In my experience Neo4j was little more than a six month waste of time and dev resources.

It looks like the source of the test is out there for others to compare/review... which is far better than many of these types of tests do. I'm not an ArrangoDB person, I've done a bit with other NoSQL variants, but will say their approach is fine. They don't even come out on top in all the tests...

It's mainly about showing how they compare performance wise, so that they can concentrate on selling based on features. Which is a pretty fair approach, and I wish them luck.

Also, in looking, it seems that they have pretty broad platform support as well.

Haha, damn... That sounds pretty harsh. Neo4J seems really interesting to me. Who doesn't want to get better with graphs? I still want to learn the query language as it is applicable to some of the problems I'm trying to solve now.

This isn't the first horror story I've heard about Neo4J so I've actually stayed away from using it professionally.