>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

>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.