> For the majority of use-cases out there, NoSQL databases offer enough consistency. For applications with a nontrivial data model, ensuring that each logical

> For the majority of use-cases out there, NoSQL databases offer enough consistency. For applications with a nontrivial data model, ensuring that each logical operation only does a single document update (or that multiple nontransactional updates cause no conflict in maintaining consistency in the presence of other logical operations) is actually really challenging - and it adds a substantial design overhead to every new feature added. I think you're being extremely optimistic in your assertion that NoSQL systems are that widely safely applicable. My experience has been that NoSQL-based systems stay mostly-consistent because they happen to experience very little concurrent activity, not through understanding/design on the users' part. This is not to make light of the situations where NoSQL systems shine, but the idea that higher levels of consistency are rarely useful does not match my experience at all. > NoSQL movement, if you wanna call it that, took off because most apps (including Google, including Financial Services, even Health Care) don't need some types of consistency offered by relational databases. I'd say that Mongo (for example) took off because: - They really nailed the setup experience for new users (which RDBMSs historically sucked at). - The data model is much easier for simple apps. - They had some fairly creative techniques for making their system look good - unacknowledged writes, and claims of support for replication which didn't really fully work. - Most programmers don't really understand the ins-and-outs of maintaining consistency.