Hacker News new | comments | show | ask | jobs | submit login

If we're comparing CouchDB's popularity to that of MongoDB's, it's simple - 10gen. 10gen has done a very good job generating lots of hype around their product. I believe they have people dedicated to this task (aka, evangelists). CouchBase on the other hand, has not done so well at this.

And that hype turned me off. I have an allergic reaction to it. Especially when they were caught acknowledging they didn't have default durability for their writes. Then suddenly they removed their benchmarks from their site and made some comment about how data will be lost anyway, so it is not a big deal.

  caught acknowledging
instant classic.

> caught acknowledging instant classic.

Those that can, comment, those that have nothing to say, make fun of those who speak English as a third language.


Feb, 2010

"We get lots of questions about why MongoDB doesn’t have full single server durability, ...there are some very practical reasons why we think single server durability is overvalued"


May, 2010

"MongoDB does not publish any official benchmarks...."

EDIT: Added link to blogs, quoted parent, in case gets removed

A moot point since single server durability is enabled by default in Mongo now, actually from the 1.8 stable (currently at 2.0 stable)

Not moot for someone who already chose a different product because of that. These decision are extrapolated and people infer the quality and seriousness of engineering from such decisions. Those, in my opinion, matter more than marketing or flashy websites.

That's a fair point, but the product as it stands is very usable for me. Even if they never updated it, I would keep this build as something that is more than adequate for what it does.

It's also that CouchDB is (or at least used to be) rather slow compared to MongoDB.

10gen sure has done a lot to keep MongoDB growing despite many people having their homework (or essential customer data, or...) eaten by MongoDB; so part of it probably is attributable to better publicity.

There is a reason they are fast. They didn't use to have durability. Think about that -- it is a database product that until the last version didn't have durability and its writes were not acknowledged with a response. If you store you data in memory and write it to disk sometimes, you can write very fast.

and now, since 2 versions, they have journaling, and offer a huge amount of flexibility over write durability available:

- fire and forget

- write with integrity check (safe)

- write with journal commit

- write with data file commit

- write with replication to X nodes

And you can combine the last 4 in any way you like.

They did a pretty good job turning a downside into a significant advantage (yes, fire and forget is a significant advantage in a lot of cases).

> and now, since 2 versions

So 20-30 days ago only?

> yes, fire and forget is a significant advantage in a lot of cases

Sorry, but not as a default option in a DATAbase product.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact