We had a production Rails app running with postgres, and we decided to implement some of our models with Neo4j. Graphs felt like the right way to represent the data, and all of the models were new, so we felt more free to choose the approach that seemed best.

A month later we rewrote everything in SQL - the main drivers were:

- as we refined our model, we realized that a relational DB with a bunch of join tables was good enough

- our developers were more comfortable working with SQL

- it wasn't possible to run complicated queries involving both databases simultaneously

- the Rails ORM felt easier to use than the Neo4j Ruby APIs (though this was certainly a function of our own familiarity with Rails and relational databases in general)

- having the extra database complicated our codebase and complicated our deployment

There was nothing horrifying or surprising in our encounter with graph databases. It just felt like we just made the wrong initial architectural decision. We were still trying to define the problem and were trying to use something we didn't fully understand.

I'd hesitate to use graph dbs in the future unless I needed a high-performance app with a lot of data that only a graph could model well. Otherwise having two different types of databases is annoying.