On Mon, Jul 5, 2010 at 5:49 PM, Volker Mische <[email protected]> wrote: > Hi All, > > delayed_commits were enabled to have better performance especially for > single writers. The price you pay for is that you potentially lose up to one > second of writes in case of a crash. > > Such a setting makes sense, though in my opinion it shouldn't be enabled by > default. I expect* that people running into performance issues at least take > a look at the README or a FAQ section somewhere. There the delayed_commit > setting could be pointed out. > > I'd like to be able to say that on a vanilla CouchDB it's hard to lose data, > but I can't atm. I'm also well aware that there will be plenty of > performance tests when 1.0 is released and people will complain (if > delayed_commits would be set to false by default) that it is horrible slow. > Though safety of the data is more important for me. > > If the only reason why delayed_commits is true by default are the > performance tests of some noobs, I really don't think it's a price worth > paying. > > *I know that in reality people don't > > I would like to see delayed_commits=false for 1.0 > > Cheers, > Volker >
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
