[Spyro7]

Maybe I'm just weird, but all of this drama around a database does not make much sense to me.

To me, it is simple. Do your research:

* Go to https://jira.mongodb.org/ and look at the issues

* Read the documentation at http://www.mongodb.org/display/DOCS/Home

More than likely, if you have to ask the question "should I use a NoSQL db" then the answer is no - just stick with SQL. MongoDB (and most other NoSQL dbs) is a specialized tool that is fit for specific use cases only.

There is no need for all of this ridiculous hyperventilating drama.

I have heard it said that the marketing department at 10gen was not good at "managing expectations". If you are working with a database, I would hope that you do not allow your expectations to be set by the marketing department. If you don't do your due diligence then you deserve to be bitten.

As to the original "Don't Use MongoDB" post. Whether it was a hoax or not was completely besides the point. Every single section in there was completely unsupported by any evidence other than the authors experience.

If you are going to talk about data loss then link to a bug report or a Google query pointing to a bug report or something. Anecdotes are not data.

[jeffdavis]

"If you are working with a database, I would hope that you do not allow your expectations to be set by the marketing department. If you don't do your due diligence then you deserve to be bitten."

That's the real definition of "hard to use": you have to research everything yourself and send the product through QA just to use it.

There's a very high value in products where you don't have to do a lot of research on the implementation quality and caveats. If you start using it, and it appears to work for your needs, you won't be bitten too badly later. In my opinion, PostgreSQL is an example of such a product.

Of course there is always some opportunity to do the wrong thing. It's a question of degree.

Following your advice would essentially mean "only big companies can ever release anything" because you'd need a team of full-time people to sit around doing research and QA for libc and the kernel and everything else you depend on.

[Lewisham]

Maybe I'm just weird, but all of this drama around a database does not make much sense to me.

Because it's the most painful point of tech. If you need to change programming languages to meet a latency requirement, that sucks. If you find your servers go down and they need rebooting, that sucks too. If you lose your data, it's gone and you can never get it back.

The troll did well to zero in on this. You don't really know how stable a database is under certain conditions until you start hitting the roadblocks. With NoSQL databases, you have less time in the wild vs RBDMSs, so anything which indicates there are hidden gotchas are going to set potential adopters' teeth on edge.

Even better, with database issues, you don't know about them until you have them, so you often do have to rely on folk knowledge about how well they turn out in practice after months/years of deployment.

It was a well-targeted troll.

[itaborai83]

and it is a easily trollable target as well. Had he tried to to attack durability on probably any other database, it probably would not have worked as well as it did.

Whether its a troll attempt or not, remains to be seen, but I completely agree with this specific, albeit very generic, part of the text.

> Databases must be right, or as-right-as-possible, b/c database mistakes are so much more severe than almost every other variation of mistake. Not only does it have the largest impact on uptime, performance, expense, and value (the inherit value of the data), but data has inertia. Migrating TBs of data on-the-fly is a massive undertaking compared to changing drcses or fixing the average logic error in your code. Recovering TBs of data while down, limited by what spindles can do for you, is a helpless feeling.

[rkalla]

Couldn't agree more about trolling the issue tracker of a project you plan on adopting. It does wonders as far as learning the ins and outs of a project and how the team works/what they prioritize.

Also, +1 on the rest of what you said.