There are different things to consider depending on whether you'd create new app alone / with trusty co-founders, or you'd want to introduce it to a team using

There are different things to consider depending on whether you'd create new app alone / with trusty co-founders, or you'd want to introduce it to a team using some form of agile development, or you'd want to expose NoSQL to people using ol' rusty waterfall model. The last case is hardest and I'll share some thoughts on it. I know most of you don't live in such environment, but still you can infer the "agile" scenarios from the waterfall one. In other words, the following waterfall issues can be areas of potential fkups using whatever development model. So, the impact of switching to NoSQL for different waterfall'ish teams: - it changes the way how your data is organized -- mostly it's denormalization and some strategies tied to the specifics of queries you'd have to use most (read: ad hoc strategies). So, it influences the analysis, architects, development & release management. - it changes the way how the db "schema" changes can be introduced. You'd say "there's no schema". Well, it's partly true, but in real life you have to add some metadata information to the underlying db, otherwise your db queries won't run. For example, Cassandra has ColumnFamilies definitions, CouchDB has its view definitions. Somebody has to agree what needs to be changed and then write these changes and maintain it in sync with the codebase. You'd probably need mechanism like Rails migrations to maintain it - you won't get rid of it with the promise "there's no schema". Somebody has to apply such changes to production as well. So, back to the waterfall: it influences analysis, development, release management & operations. - it changes the way how your app scales. The goal of many NoSQL engines is to easily scale horizontally -- this is a big win to operations! But we're not there yet (Cassandra? Maybe MongoDB?), see eg. http://bjclark.me/2009/08/04/nosql-if-only-it-was-that-easy/ http://bjclark.me/2009/08/04/nosql-if-only-it-was-that-easy/. Also, if something you need crucially doesn't scale, you have to redesign your app. So the influence is: operations have less work, release management has more work, but in the worst case all the teams have to rework the app. - it allows for some non-standard app behaviours. Eg. CouchDB is excellent at disconnencted operations, meaning: ocasionally synchronizing data between nodes which are mostly offline. It's also called "no master" as opposed to "multi master". No wonder IBM research funded CouchDB development (trying to rewrite Lotus Notes? ;) and also Ubuntu chose it for their Ubuntu One sharing platform. Feature like this is a relief for release mgmt & operations, but can need a lots of work from the architects, analysis & devs. Hope this is useful. I'm considering convincing some BigCorp to use NoSQL in some project and these are the issues I thought of.