The same argument about branches in source control can made about SQL itself. In my opinion, a large number of developers don't know how to code SQL properly and a lot are afraid of it. They end up using an RDBMS as nothing more than a dumb bit bucket -- often hidden behind increasingly complex abstractions. The NoSQL movement, unintentionally, lets these programmers feel superior about their lack of knowledge.

I don't want to argue against the legitimate use of NoSQL solutions. I just don't think there are enough use-cases to justify the hype. For example, an article was posted here last week about using NoSQL solution to store e-commerce orders.

I disagree. Lots of applications only require dumb bit buckets. There is no real sophistication or structure to the data. Anything more is over engineering for a large majority of products which data storage is not particularly useful or meaningful.

I worked on a system a couple of years ago where we ran calculations nightly and then we write the results of this calculation to a row in a table for caching purposes. This row was then fetched by another job to generate a PDF. We used SQL for this because Reporting Services could build a pdf from a row in a table.

It's not a good solution. This type of data doesn't need to be searchable. It's using a database server as a caching mechanism. That seems wrong. Seems like memcached, mongo, couch, or anything else would have been better.

Heck, people have been using memcached for a long time, and yet all of a sudden people don't see a use for NoSQL setups?

Are we sure we're not just doing the same old "Defend what you know" dance?

"SVN vs Git"

An excellent comparative case in point that in my opinion actually undercuts what you are asserting.

You do not lose features and functionality in that transition (where as noSQL is by design reductive), and further, Git is a replacement for SVN and not a complementary tool.

Actually you do lose functionality by going that way. SVN handles binaries better. I can also cherry-pick files from a directory structure, so if I need to fetch out a subfolder or an individual file, I can do so. With Git I must clone the repo or set up a web service so I can get access to the file system. But they're different tools for different audiences. In my environment, I do use both of these tools together.

The lesson Git, Ruby, Subversion, Apache, and many other projects have taught me is that instead of saying "What I have is fine, I don't need what you have", I need to ask "Why do you use what you use, why does it help you, and how might it help me?