Not only do I think there's a lot of benefit in representing data for which the schema is already fixed, we've actually gone to the extent of showing this by bu

Not only do I think there's a lot of benefit in representing data for which the schema is already fixed, we've actually gone to the extent of showing this by building a whole replica website for Stack Overflow. https://github.com/dgraph-io/graphoverflow https://github.com/dgraph-io/graphoverflow (unmaintained, so please don't complain if it doesn't work :-)). If you build systems like inventory tracking, question answering, etc., the hard logic of relevant data retrieval can either lie in your application or within your DB. Former is the case when you use relational DBs, latter is the case when you use graph DBs. With graph DB, you can put the data together quickly, but then have the DB do the hardlifting of "given a customer, find me all the items and the locations of delivery" (just random Q that I spent 2 seconds, not representative of real workload); or "given a question, find me all the answers, sorted by a score; top 5 comments on these answers sorted by date, with a count of total comments, count of likes, count of dislikes, etc." (real workload for QA sites). Then the application iteration becomes largely a factor of query iteration, not backend logic iteration. ^ And that's solid! That kind of stuff is what makes developers love JS over C++ (random comparison).