We switched from SQL to Mongo on http://versus.com one year ago and are quite happy—we couldn't imagine to go back.
But I think it heavily depends on the specific use case what DB to use.
But I think it heavily depends on the specific use case what DB to use.
My problem with NoSQL is that you MUST know there won't be changing requirements:
Later you might need to do the equivalent of joining 3-4 tables. Then you have trouble... But I'm a coward that look both left and right before crossing a street.
Because it is schema less and document based you can trivially add new rich schemas to existing documents. And in the case of doing joins you can always do it in application layer or using DBRef or MapReduce. There are valid options that are still quite performant.
Just today I enjoyed explaining to a developer why his insert into a timestamp failed because of formatting, with a nice english error message. Thanks Postgres!
Whereas the same thing last year with Mongo just inserted the wrong date into a misspelled key and we didn't figure it out for days.
I thought the main advantage of document-oriented schema-less databases (I haven't used MongoDB but I have used CouchDB) was that they are supposed to give more flexibility in the early stages of projects.
NB Personally, I've moved to PostgreSQL and its JSON storage as then you get most of the benefits of both worlds.
Depends on your requirements, I guess. If you want to maintain even eventual consistency, any update that crosses document boundaries has to be thought about very seriously in order to avoid breakages in the face of concurrent modifications. So, ideally you design your documents such that any one logical operation only has to hit one document.
This is pretty easy for very simple tasks, but can get rapidly more difficult in the face of more complex or changing requirements. I suspect a substantial proportion of Mongo or Couch based applications simply ignore this problem, and are lucky that they don't have enough concurrent activity that stuff breaks frequently.
Using Postgres/JSON neatly avoids this problem because you get ACID back, and you can do cross-document updates all you like.
I agree with what you wrote.
But my point is that _changing_ requirements can screw you, if you find that you _later_ need relational capabilities.