Comment Re:Call me skeptical (Score 1) 222
There are certainly many cases where there are advantages of non-relational systems as layers in the application that complement standard relational databases. Generally frequently read data that does not need to be queried at a granular level, like say session data, or geographical mapping tables. Some good complementary examples include memcache, redis or even ruby's starling. I use many of these in my applications, where honestly MySQL would probably work, but these other solutions provide many performance and cost advantages that simply can not be overlooked. Some, like starling, I've used to simply cache data on disk that does not change often, or lists in Redis to store map data.
IMO it's often easy to say SQL will work so use that, but it's not always the best solution. Sure you can get it to scale; I've used it in very massive petabyte scale without very much issue... but sometimes for smaller sets of data frequently accessed do you really want to invest in the kind of hardware required to make SQL run well, or will an in memory store on commodity hardware work as well or better? Sometimes you have massive data going in where neither SQL nor NoSQL are going to help you, where maybe hadoop or another map-reduce type solution is more appropriate.
It generally comes down to the questions; what type of data are you storing, how much data will there be, how are you going to use that data and at what levels of latency do you require for reads and writes? Before those are well defined you really are shooting in the dark on solutions to store and access it. This IMO is really the major issue most startups have, no one defined the data strategy, they just build with no conscious effort to examine what the business needs are short and long term.