Hacker News new | comments | show | ask | jobs | submit login

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.

My instinct is that using two different databases in one app adds a lot of complexity, but it's not clear to me that if you need to pick one database that SQL is a better choice than a graph database. It really depends on the application. For many purposes, a graph database can do what a SQL database can do, because a SQL TABLE is very much like a graph collection of nodes. Of course, if you're starting with an app on a SQL database and just adding to it, that's very different from a "green field" project where you can pick technologies freely.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact