While the article was interesting, I completely missed the significance of the two code examples. The second example of creating a graph query in SQL via temporary tables brings back some MySql nightmares. I was late to realize the first example was a three line replacement with a graph DB. That is sweet!
I'm interested in Graph Databases myself, they seem to be an interesting new direction.
NoSQL never interested me much -- it felt like just throwing something away (relational), without really getting much in return (I found the performance of PostgreSQL good enough for any purposes I've had personally).
NoSQL is a very wide field. There are lots of special cases in which certain NoSQL data stores can help a lot. One of the points the posted article makes is that native multi-model databases help you not to sacrifice relational and yet reap some of the benefits certain NoSQL data models (like graph) can provide.
Postgres is definitely a great choice if you want a taste of NoSQL-like flexibility while staying in the familiar SQL world. In my eyes, ArangoDB provides similar benefits if you want to move beyond SQL without going "all in" with a pure graph database.
You can model your data as documents and use arbitrary joins to start with and then restructure your data in terms of edges and vectors when you run into situations where you would benefit from graph queries. It's not either-or and because ArangoDB is multi-model you can mix both approaches in the same queries.
Does anybody reading this have any experience with the performance of AWS Neptune? I would be very interested to hear about the performance of deep graph traversals on large sharded graphs.
