What I find interesting is that every single time I bring up MongoDB's lack of master-master architecture/replication on Hacker News the response I get is relat

What I find interesting is that every single time I bring up MongoDB's lack of master-master architecture/replication on Hacker News the response I get is related to the fact that MongoDB has a master-slave architecture. Sure, it might work for some applications well, but master-master is a better choice for typical NoSQL uses. The whole point of master-master is not dealing with failure situations or trying to scale out performance (even though master-master handles those situations naturally), the point is that it's a different philosophy. The idea is that there's no single official true state of the database. Reality happens to map that idea very well. The data doesn't exist in a centralized official place, it exists in multiple places which may not be perfectly connected in real time all the time. The data exists at multiple servers at multiple databases. It exists on your mobile device, sometimes disconnected from the server. It exists on thousands of browsers on the same time. There's no single master. The best mapping of this reality is the master-master ideology. Yes, it requires application-level merges of data, but the benefits you get from implementing this can be tremendous. And that's why I'm excited about using CouchDB. Or rather I'm excited about master-master databases. CouchDB happens to be one of those, and I hope future databases will be built around that too.