No, just that there's an upside to their risky design philosophy.

I like Mongo because of its documentation. It's really really great. And good documentation = widespread adoption, and a team who actually cares about user's needs. What they really need is a lengthy tutorial on backups (which they already have written), linked from every page in their documentation. Because their reliability not something they should be hiding.

Sure there is an upside, nothing against, but the trade-off they made should have been advertised on their front page (before they fixed the defaults) in large bold flashing letters -- "you might lose your data if you use this product with default options". That is all.

Why? Because they are making a database not an rrd logger or in memory caching server.

> What they really need is a lengthy tutorial on backups.

As I put it the grandparent post, as a general rule, avoid products whose mission is by design to teach you backup discipline. That is all.

> a team who actually cares about user's needs.

You know what is a better way to care about users' needs? Not losing their data because of a bad design. We are not talking about generating a wrong color for a webpage or even exceptions that are thrown and server needing restart, we are talking about data being corrupted silently without users noticing. Guess what, even backups become useless. You have no idea your data is corrupted, so you keep backing up corrupted data.