Perhaps OT, but can someone explain how graph databases are useful? I've read through their site, but don't have a good handle on when I'd select a graph database over an RDBMS, document store or KV store. Also, how is scaling one of these different or the same as an RDBMS?
i am not a great fan of them, so i am both biassed and inexperienced, but it seems to me that they win out over SQL in cases where you would be doing recursive queries. this is typically the case when you don't have much structure in your database (everything is related to everything else in one big table) and/or when you need to jump across an uncertain number of joins (to answer questions like "how many steps does it need to get from here to there?").
compared to KV they place more logic in the database (much like SQL v KV).
I'd agree with Andrew's general characterization of graph database advantages. Graphs are "whiteboard friendly" in as much as you can store data exactly as you would likely sketch it up when thinking purely in your domain. Because the graph structure is generic, you can even happily use it as a key-value or document storage. And, multiple intersecting domains can co-exist within the same graph. A graph could be a simple list, a map, a tree, or a complex network of data. With Neo4j, you'd get that expressiveness with the confidence of ACID behavior.
Beyond that, the Not-Only SQL options are a reminder to pick the storage that fits your application, rather than fit your application to the storage you have. Be domain appropriate.
I usually think in terms of:
RDBMS - when aggregating data is important
Graphs - when relationships between records matters
KV - when you have really simple data, but gazillions of records
Document - when you have complex, but unrelated and possibly non-uniform data
