The most interesting part is to make a difference between your primary data store and your secondari(es) ones. For "friends of friends" queries you could defini

The most interesting part is to make a difference between your primary data store and your secondari(es) ones. For "friends of friends" queries you could definitely use graph dbs, for "tree hierarchical" data then a document based is good. Secondary dbs are chosen depending on queries. For analytics then choose columnar dbs or map/reduce friendly data stores, etc... But primary db needs powerful querying possibilities, strong consistency and durability,as well as really good admin toolings. That's the "fall back", to be used as a last resort, but that's also the point of truth of your system. Then comes optimizations, and pipe-like data processing to move data from primary to secondary dbs ( or to both in parallel). That's why i've never been found of using new technologies such as mongodb or couchdb or anything like that for my primary db.