I think there are times when the graph model shines. https://theburningmonk.com/2015/04/modelling-game-economy-with-neo4j/ https://theburningmonk.com/2015/04/m

I think there are times when the graph model shines. https://theburningmonk.com/2015/04/modelling-game-economy-with-neo4j/ https://theburningmonk.com/2015/04/modelling-game-economy-wi... I read this article I found on HN a few years ago, and for some reason it came to my mind just now. The neat thing about the graph model of course is being more immediately expressive to the query-er, and that takes cognitive load away from that person. I'll never say a bad thing about SQL or the relational model. I completely agree that it's superior in terms of flexibility, performance (almost always), modelling (usually), etc but I guess there are times where you have a weird project and it's just I guess the convenience and ease of using Neo4j and a few cypher queries and then it's over. In the case of the article I linked, there is also the benefit of having a convenient way to see how changes echo throughout the graph, something that is more involved to do with tables and joins and all that. I'm not a DBA, I've really only ever dabbled, but if I got dropped into that situation and DIDN'T have a graph model, I'd have no clue where to even start. Maybe I'd start trying to walk tables and build graphs out from each item type to each other item type. That'd be gross. Of course, that's probably not a problem scenario that comes up very often. Most of the times I've interacted with databases in general I've been just dealing with sanitizing params, getting HTTPS configurations configurated, just boring infosec stuff. That problem is probably very rare in the realm of "problems that graph seems to have an advantage" Anyways, yeah. Relational, awesome. Graphs, sometimes convenient.