Hacker News new | ask | show | jobs
by rit 4618 days ago
I worked for 10gen (now MongoDB) for over 2 years (I left in December).

Never once while I was there did they publish a benchmark: There was a [publicly] stated company policy to not publish or comment on benchmarks.

If you have evidence otherwise (i.e. benchmarks published by the folks working on MongoDB) fine, but I take this as a deliberately inflammatory (and false) statement.

EDIT: The global write lock was removed ~last August; there is now a database level lock. Future releases will likely make that more fine grained. Additionally, the drivers no longer do "unsafe" writes, but check w/ server.. as of the same release.
2 comments
justinsb 4618 days ago
It is not a sin of commission Mongo is accused of, but a sin of omission. MongoDB out of the box is configured to be fast-but-unsafe. Postgres and other databases out of the box are configured to be safe-even-if-slower. A benchmark which doesn't spend the time to configure both systems equivalently (i.e. most community benchmarks) will therefore show MongoDB as the faster system. The policy of not publishing/commenting on benchmarks simply allows misleading benchmarks to be created and to stand. It's a self-serving policy.

Mongo has repeatedly chosen defaults for their database which make naive benchmarks look better, at the expense of production safety. You seem to be willing to attribute that to Mongo's incompetence. Proverbs are on your side, but it sure ties in nicely with the "leave the benchmarks to the community" policy.

link
mdellabitta 4618 days ago
> database level lock

But that's not anywhere close to good enough.

link
lowboy 4618 days ago
> But that's not anywhere close to good enough for me

FTFY

link
mdellabitta 4617 days ago
> But that's not anywhere close to good enough for concurrent, multiuser systems with reasonable traffic.

FTFY

link
lowboy 4617 days ago
Mmhmm. Like I said, that's not good enough for you and for your needs. For other people it's fine. That's important to note.
link
lucian1900 4617 days ago
At that point you might as well use a JSON file per database and lock the entire file, parse, change then serialise again. That might even be faster.
link