Ask HN: If you've used a graph database, would you use it again?
There is a lot of stigma attached to graph DBs. Would it provide good performance? Should I ever use it as my primary database? Is my data ever safe with a graph DB?<p>If we go beyond that, assuming there was one which provided great performance, data integrity and can be reliable as a primary database — then Graph DBs are just better.<p>First, the schema and data modeling is incredibly simple. Our minds think in graph terms. Things connecting to each other is very natural to us as human beings. Graph DBs replicate that in a very straightforward way.<p>Then, many graph DBs, being modern support flexible schemas, something which is a huge win for speed of application iteration.<p>Graph DBs are also sparse. Which means it&#x27;s a lot easier to model many differents kinds of data sources and data types into the same &quot;table.&quot; What that gives is the ability to query across anything in the entire DB, without being concerned about table level boundaries.<p>We were solving this problem with Google&#x27;s knowledge graph where we had to fit movie dataset in DB. The film industry has so many roles (director, producer, actor, cinematographer, and so on), that having a table for each, with many times same person doing multiple roles, is just super fucking hard. With hundreds of such roles, each role being a table would be insane. Representing this information in graphs is a cakewalk in comparison. And this problem gets a lot worse if you then switch to the music industry, books and others (hence, the decision to be a knowledge &quot;graph&quot;).<p>Functionality wise, graph DBs provide a super set of SQL. They support all the (equivalent of) select x from y where z type statements, while also doing fast and recursive traversals and joins at the DB level.<p>And recursive traversals and joins are a huge deal. The rise of GraphQL over REST APIs is in a way indicative of that. To render a page in modern websites, you need to recursively ask for components (think questions in Quora or Stack Overflow). I remember Quora would have thousands of such components on a single page. GraphQL made it easier to query for those, by expressing a way to retrieve this tree in a single query. But, the internal mechanics of doing this via relational tables is still the same, which is to repeat a query and collect cycle. Graph DBs natively support things like these, and imagine how much more efficient and powerful that is.<p>Once you start to wrap your head around graphs, it’s hard to not be wholeheartedly impressed by their power.<p>Disclaimer: I&#x27;m author of dgraph.io. But, don&#x27;t let genetic fallacy blind you. My points above stem from the reasons which propelled me to jump into the graph DB world.