To Klaus's point, we have to choose our FUD: "CouchDB is sooo slow" or "CouchDB will lose your data"
Would the latter cause more harm than the former? I don't know, but Google already includes the phrase "mongodb losing data" in its search suggestions. I'd hate for CouchDB to end up in the same boat. On Tue, Jul 6, 2010 at 3:07 PM, Klaus Trainer <[email protected]> wrote: > 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 > > >
