You're right. I just meant a little different thing: that we'd better store JSON in conventional way of storing values in schema-full columns. For example, obje

You're right. I just meant a little different thing: that we'd better store JSON in conventional way of storing values in schema-full columns. For example, object {foo: {bar: [1, 2], a: 'b'}} would be three columns foo.bar.0=1, foo.bar.1=2, and foo.bar.a='b'. In medium-sized project you'll write DAO layer to convert DBMS view on data to application code view on data anyway for various purposes. It would be even better, because column order in SQL doesn't matter (but in Mongo it does for searching, as it's essentially just BSON string). And column names won't be repeated each time and take space. Of course, if you have a case to store unstructured data where you don't know the structure in advance, in this case it won't work for you. But for your own data -- we'd better let DBMS maintain the schema, instead of maintaining it in application code (inventing the wheel). Side note, regarding updates of particular fields in objects: a NoSQL datastore must provide some "compare-and-set" functionality to avoid race conditions during updates. PostgreSQL way is to use row-level-locking transactions, but MongoDB locks the whole collections (well, several months ago it blocked the whole database, so it's and improvement :). They kinda offer findAndUpdate() for "compare-and-set", but see my another comment below on why it doesn't work.