NoSQL vs. SQL - Adhoc vs. Upfront design
Bozho writes on his blog 'Why Startups Should Not Choose NoSQL' that '... you must know what will be the questions that you will be asking upfront. You can’t just query anything you like.' To an extent, he's right. Whereas I can craft any random ad-hoc query on a SQL database, I have to do some work on a NoSQL database to get at that same data. But at the same time, there are plenty of questions I might not know to ask that are still stored in my database. In my current project, I'm doing iterative development, storing data that I absolutely need first. Some of this data is being collected without really knowing how I'm going to use it - how I'm going to create accelerators to accessing the data. But the technology gives me the data and the tools to allow me to create these things after the fact. Performing iterative tasks, I can create new indexes and collections of data to answer questions I had no idea I'm going to need.
The downside, and this is something that has traditionally been shared by OORDBMs in the past, is that end-users using a tool like Excel or Crystal would be hard-pressed to create adhoc queries from their databases. This is one of the powerful features that has made SQL kind of the database community for so long. At the same time, I think the NoSQL movement is different, in that there is already work underway to create libraries that interface with multiple NoSQL databases to provide something akin to ODBC in the SQL world.
At the same time, I also do not foresee the end of the SQL realm - SQL still offers much. There is a place for both.