If there's one thing the NoSQL community can definitely agree on, it's that relational databases are not the one and only solution to modern data storage issues. Not that they're never the answer; just not always the answer. The key, then, is understanding which tool is needed for any given job. In this recent article from Rik Van Bruggen, a use case is presented that calls a database far more flexible than the relational model: the graph database.
According to Van Bruggen, the advantage of graph databases is all in the design:
Rather than relying on complex relational databases (as conventional business databases are called) to store and analyse data, graph databases allow users to store, search and query complex interconnected content... A graph database does this by applying graph algorithms to the data and leveraging relationships and connections between physical assets (people, objects), their locations and subjects and matching complex patterns to make sense of the information.
Or, in short:
...graph databases can identify complex relationships between data
The real-world use case Van Bruggen provides is that of Shutl, a delivery service based in London. Their data needs - complex and interconnected - made them an ideal fit, according to Van Bruggen, for a graph database, which in their case led them to Neo4j. The performance improvements were fairly impressive:
...Shutl observed that before turning to graphs the latency of their longest query was higher than their shortest physical delivery, both around 15 minutes - something that can no longer be replicated as the average query is powered by a graph database and takes 1/50th of a second!