couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zachary Zolton <>
Subject Re: delayed_commits false
Date Tue, 06 Jul 2010 20:22:10 GMT
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

I'd hate for CouchDB to end up in the same boat.

On Tue, Jul 6, 2010 at 3:07 PM, Klaus Trainer <> 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

View raw message