To graph or not to graph, that really shouldn't be a question!

If you’ve talked to me in the past two and a half years, you have probably been thinking “oh, will he ever shut up about those graph databases”. I am sorry to say I won’t, and here is why

• Graphs are the most natural representation we have of how (most) data is created in real life, i.e., not as islands, but in relation to other data points. For example, it doesn’t make much sense to look at me as, say, a customer without all the context (age, address, type of employment, purchasing behavior, etc.) that describes me as a customer. In relational databases you tend to tear the relations apart (making the name somewhat of a misnomer) and shove each data type into its own table, only to have to recreate the relations when they are relevant… which is all the time
• They are a major timesaver! Would you rather write 5-10 lines of code that gets right at the heart of a complex problem or write 100+ lines of convoluted JOINs to create temporary tables before finally starting to extract the insight you were looking for? If your answer was the former, then you want a graph database
• Needless to say, fewer lines of much more intuitively understandable code, means fewer errors and easier onboarding of newcomers, not to mention quicker time to value creation
• Besides reducing the amount of time spent coding, seeking out complex patterns such as fraud, spending or key people in a network can be done in seconds on a graph database rather than minutes, hours, days if at all possible with a relational database. Ever had slow query responses in the morning? This is often because servers are busy running complex overnight queries/data updates that spill into the morning. Your IT department might want to consider if they are solving a graph problem with a relational approach
• Though I don’t have the data to substantiate it, graph databases should be greener query-for-query than relational databases when running queries involving traversal of several relationships (which means most queries beyond summary stats and two-JOIN statements), simply because this is what graph databases are optimized to do
• You can get a birds-eye view of how your data is interlinked, i.e., you can literally see how everything is connected, which is interesting, e.g., when investigating fraud

... There are plenty more reasons, but I'll stop here and instead provide some answers to the most common objections (I am inclined to write swan songs) espoused against adopting graphs

• “I can just write another view to cater for that” to which I would answer, “sure (maybe), but why would you want to spend your (employer’s) time doing so?”. Will you construct a view for every question that hasn’t been thought of yet of which many will only be of temporary interest? How about building a knowledge graph? … Not wanting to use the right tool for the job, is like hiring a carpenter who insists on using a screwdriver for every task
• “with proper indexing my relational database is just as good as your graph.” For graph-type problems, really it isn’t as you have huge overheads in searching through data that is not relevant to the query whereas graph queries start with only the nodes fitting set criteria. And even if you are the supreme overlord of indexing, then have fun doing so as more and more data sources get added and require joining based on everchanging requirements to provide answers ASAP
• “everyone knows SQL, why should we spend time learning a new language.” First of all, it may not be everyone who needs to learn graph… yet. Second, because the data is already connected you don’t have to spend as much time learning about different joins, unions, temporary tables, schemas, etc., so spending just 5 hours on online courses will allow you to write queries that grabble with pretty complex questions. I would encourage appointing some champions (your data scientists should be salivating at this) that can be frontrunners on this and evangelize within your organization. In addition, rather than having new-joiners inducted in the SQL-devotee cult, teach them that some cases are best solved using SQL others using graphs
• “our organization is already knee-deep in RDBMS, why should we put money into graph database licenses?” There are at least two answers to this: 1) maybe you should seriously reconsider how many of your jobs are actually graph-type and start converting them to graph databases, which will save runtime, reduce the number of lines of code to maintain by a factor 10 or more and allow you to do away with some of those license costs, and 2) getting your data into graph databases will unlock insights and new avenues for growth not possible with only RDBMS. (NB! You may have to nudge some of your data engineers and architects rather sternly to get them to admit/realize that their RDBMS paradigm is not the answer to everything)
• “from what I’ve heard, graphs don’t scale.” That is a matter of perspective. Last year, Neo4j showed real-time query performance against a graph with over 200 billion nodes and more than a trillion relationships. Try to put that in your relational database and query it (for graph-patterns)

In summary, are graph databases inherently better than relational databases? Or other types of databases for that matter? No, but they are better at solving questions of a graph nature, which simply come up time and time again. I understand that it may be hard for some, who have worked in SQL for 20 years or have been designing schemas for RDBM systems to suddenly have to embrace the graph approach. But really, trying to solve graph problems with a relational database is like bringing a bike to a formula 1 race, you may get through, but only when everyone else has finished, celebrated, packed up, and moved on to the next race.