couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mikeal Rogers <>
Subject Re: delayed_commits false
Date Tue, 06 Jul 2010 20:34:07 GMT
The difference between delayed-commits on and off is not the biggest
difference in consistency and durability between mongo and couch.

MongoDB doesn't return a response by default on a write. You just write to
the socket and hope that it's available.

MongoDB lets the kernel decide to flush to disc whenever. Newer version
force an fsync every minute.

MongoDB writes to their file format "in place" and don't keep *anything*
append-only around which is why they suffer from these kinds of long term
corruption bugs where data can't be recovered.

These things don't just set MongoDB apart from CouchDB in terms of
consistency and durability they set them apart from all other modern
databases. Even Redis has more consistency and durability than this.


On Tue, Jul 6, 2010 at 1:22 PM, Zachary Zolton <>wrote:

> 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 <>
> 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
> >
> >
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message