I guess this is a history repeating itself - before RDBMS there were hierarchical dbs, and other such technologies. There was a reason why RDBMS won the battle.

I guess this is a history repeating itself - before RDBMS there were hierarchical dbs, and other such technologies. There was a reason why RDBMS won the battle. And probably the top most reason was the simplicity with which you can define relation ship between data, store this data(with relationship) and access it easily. We are all use to using SQL, and even though with all the ORMs in the world, it is still probably a very simple(yet powerful) language. If you look at HTTP, the corner stone of web, one of the reasons it has been so popular, is because of it's simplicity yet powerful. And it can thought to represent the same simplicity as RDBBMS (everything revolves around some really basic operations - read, write, update, delete <-> GET, POST, PUT, DELETE). And historically, invariability the technologies which hides the complexity of what they do by providing a simple interface, normally win. And that was one of the main reasons for the success of RDBMS. And which still remains true. And that was precisely the reason why every one started using RDBMS for blog type application, even though it is not the best use of RDBMS. Come to think of it, why would you want to store lot of text (content of each blog) for each blog id in RDBMS - but people did (because it was so simple to do, and that is what they are used to). Hence the use of RDBMS for these type of applications was debatable to begin with. However if you look at transactions management that is required by some of the financial applications, for example, I doubt how far the NOSQL solutions will go in satisfying the requirement. With regards to the scalability, I will not get into the cost factor. Because there are different ways of calculating the actual "cost" of something - if you are Google - the cost of having few PhDs writing your own filesystem and db(or NOSQL) is not much compared to the benefits you are going to get out of it. But if you are not Google, it is a different story. So if we leave the cost factor aside, for a moment, the list of options available with some of the high end RDBMS technologies(with regards to performance), for example Oracle, are quite broad - from active/active clustering technologies(RAC), from different indexing types(b-tree, bitmap, clustered, index-organized), multitude of partitioning types - range based, hash-based(combination of these), list based etc, the list goes on. Same is true about Subase or SQL server(except of active/active clustering). So I am sure the performance issues can be handled in these RDBMS technologies (without just throwing hardware at it).