> 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.

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.

>>[NoSQL] are supposed to give more flexibility in the early stages of projects

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.

Well, that's why I gave up on CouchDB once I found that I was actually much happier with the hybrid approach of using JSON documents inside a relational structure.