There is some hype around graph databases. I'm wondering why.
What are the possible problems that one can be confronted with in today's web environment that can be solved using graph databases? And are graph databases suitable for classical applications, i.e. can one be used as a drop-in replacement for a Relational Database? So in fact it's two questions in one.
Related: Has anyone used Graph-based Databases (http://neo4j.org/)?
Many relational representations of graphs aren't particularly efficient for all operations you might want to perform.
For example, if one wants the connected set of all nodes where edges satisfy a given predicate, starting from a given node, there's no natural way in SQL to express that. Likely you'll either do a query for edges with the predicate, and then have to exclude disconnected edges locally, or have a very verbose conversation with the database server following one set of links to the next in iterated queries.
Graphs aren't a general replacement for relational databases. RDBs deal primarily in sets (tables), while graphs are primarily interesting because of the "shape" of interconnections. With relational DBs you follow links of a predetermined depth (a fixed number of joins) between sets, with results progressively filtered and grouped, while graphs are usually navigated to arbitrary and recursively-defined depth (i.e. not a predetermined number of "joins"). You can abuse either to match the characteristics of the other, but they'll have different strengths.
In my opinion, social networking sites may benefit from graph databases because graph is a natural way of storing connections between users.
You will find some answers in these two stackoverflow threads:
Regarding classical apps, this Neo4j wiki page could be of interest: Domain Modeling Gallery (I wrote it).