The actual 900% argument is buried in the comments of a frustrated user who said almost nothing about technical parameters of his experiment.

Please don't submit a title like that next time.

My apologies if I wasn't clear enough.

The comment (which is what I linked directly to) came from the writer of the actual blog, who is one of the main developers for the Mongo DB PHP driver. http://www.snailinaturtleneck.com/blog/about/

So I would take it with far more than a pinch of salt.

Yeah well somehow the link doesn't redirect to the actual comment so we see just a blog entry; and now the 900% comment got rotated out from the entry page.

Thank you, you seem to have corrected the title of your submission.

Still I'm not sure such thing is worth posting to HN at all. Little technical value, just spreading the information that somebody is not satisfied with something. This is what I call "emotion flush". Do we really care?

Please note I'm not attempting to bash specifically you but rather thinking of improving general quality of HN links.

If you have the right job for the tool... these tradeoffs should make a lot sense.

Right ... but the rise of NoSql is predicated on the 'fact' that RDBMS's can't perform near as well as NoSQL stores.

But it seems like the claim made on http://www.mikealrogers.com/2010/07/mongodb-performance-dura... that with an in-memory version of Postgres "once you turn off the log and all the durability it’s neck and neck with MongoDB write performance" ... might not be so far off the mark.

With equivalent OS interaction, and no JOINs/seeks, the RDBMS could actually be faster, as there is no overhead of storing the name of every col in every record.

I still like MongoDB though. During dev it's nice to not have to worry so much about schema, run ALTER, etc.

What possible benefit justifies writing the code to be little-endian only? Why on earth would anyone do that?

It's not a trade-off if there's no upside.