Some updates are done in place, some are not. To give a specific example - integer updates are always done in place. The most common reason that a document has to be rewritten is when it is updated size is too big to fit into its previous space. Then it has to be moved.
Could be, but that article just says that the update is "in place." Which may mean that just the changed int is written, or it may be the entire document.
But, it's in the box API functionality... since it's a single record, there's minimal locking involved. Depending on your load that can be very important.
For that matter, imho doing a locked partial update via something like _.assign would be fine imho in postgres. It depends on how you really need to use your data... and how it fits into that.
If you have a lot of recursion in your data, it may be better suited towards sql... if you have a lot of data gathered around a group of objects/documents a document db like mongo/rethink/elasticsearch may be best... if you really need key/value lookups, then cassandra is hard to beat.
For that matter, having data duplicated/replicated to multiple types of db servers is entirely reasonable. You management UI can interact with an SQL datastore, and on save, you also save to Mongo.
That was the interim step I chose in migrating our data structures.. the queries that run against mongo work great, there's three servers in the replica set, for a relatively small data set, and it is really nice.
Right. It's a confusing space because even though couch/riak/mongo are all "document databases" their storage engines are very different. You can't usefully generalize from couch's append-only b-tree to mongodb's mmap'd data files.
