Just to put my two cents in... It's a matter of to be or not to be (ACID (by default)).
With delayed_commits=true, data operations aren't durable anymore. Consequently, if it's the default setting, some people might say that CouchDB does not meet ACID requirements. People mostly tend to simplify. We will hardly be able to eliminate (sometimes vicious) superficiality, but we rather should face the fact that such partially true assertions may be harmful. Take MySQL as an example: there are (still) people stating that MySQL is not ACID compliant and doesn't support transactions. They are partially right with that: it's true for the default storage engine (MyISAM), but definitely not for InnoDB. With choosing stronger guarantees by default--as long as it goes in line with basic design decisions--we just eliminate any room for such confusion (or maybe even FUD that is spread by competitors). Basically, when comparing with other databases, that's way more important than a higher rank in an inadequate performance benchmark (pissing contest). - Klaus On Tue, 2010-07-06 at 16:43 +0200, Benoit Chesneau wrote: > I would prefer to put delayed_commits=false too, to keep the promise > we give to our users. We can't say on one side we are better than > mongo for this while a simple power failure may result in lost of data > by default (even if we are better since dbs won't be corrupted). > > The default should be the strongest imo. Like every os should be > secure by default, we should let the user know, we do the best *by > default* to make sure data are safe on the disk. While they still have > the possibility to bypass this "security" . But in this case, this is > a choice. > > For those who worry about the marketing, this is also a good point of > differentiation compared to others dbs. (/me remove his marketing hat) > . > > - benoit
