Part 2: What is a graph database
Part 3: Rapid prototyping
I am very excited to share tremendous experience I had with graph databases (Neo4j specifically), and how going schema-less first (and hybrid or schema-full later) changed my approach to design software. This topic is orthogonal to "NoSQL", the term that holds the second place ("cloud" being the first) in overuse and ambiguity.
For many years, my "to go" (and only) option to do any database work was Microsoft SQL Server. It was easy and natural to open Management Studio and start writing SQL queries. Plus, vast and mature tooling, integration options, language support, community and documentation... you name it.
On my recent project, however, I needed some graph-related functionality (like friends of my friends who liked posts I liked), and I just couldn't get an acceptable performance with SQL Server. I found some 3rd-party solutions on top of SQL Server, that would persist a graph in some way and then reconstruct it in memory for fast traversals. That sounded horrifying, so it was the time for me to take a good look at the graph databases.1
"Where have you been all my life"Looking back at all my previous projects, I would estimate that a graph database would've been a better choice (over a SQL database) in 80% of cases. And, I would always use it for the initial design and prototyping. I do not feel too bad, however, as the graph databases really came to maturation about 3 years ago.
1 You can find a good description of a graph database on Wikipedia.
2 The ranked list of the most popular graph databases is here.