MongoDB Is Considered Harmful and should not be used due to its data corruption and security issues.

[duaneking]

I want to preface this with the statement that I know a lot of people rag on MongoDB for no reason other than to try to act popular or cool because they don't understand the technical issues and often simply parrot that MongoDB is bad; So I need to stress that is not what I'm doing here.

I'm calling out MongoDB as a bad option because of its technical limitations and not dogma; I'm calling out its lack of engineering excellence, not claiming that its uncool. In short, I'm saying its uncool, but I'm giving you valid technical reasons for it. So my issue here is purely technical from an engineering perspective.

I highly suggest you read these and learn yourself:

• https://gist.github.com/mitio/1343383
• http://cryto.net/~joepie91/blog/2015/07/19/why-you-should-never-ever-ever-use-mongodb/

[NetOpWibby]

I have no horse in this race but a comment on the gist you shared links to a discussion on HN where the claims that gist posits were debunked.

Also, the links you shared are super old as far as the web industry is concerned which means they're probably irrelevant. But hey I prefer RethinkDB, a "dead" database so maybe my analysis isn't to your liking.

[duaneking]

Not true.

It linked to a HN discussion where the CEO of the company involved explicitly stated that the defaults are bad just like I said.

To quote that CEO/thread at the claim of "1. MongoDB issues writes in unsafe ways by default in order to win benchmarks" he cites "To be fair, the uses of MongoDB have shifted a great deal since then, so perhaps the defaults could change."

He also explicitly calls out that MongoDB MUST be used in an overly sharded way to be safe, explicitly calling out propagation strategies most companies refuse to do due to cost as minimal requirements to use it safely. If your going to spend that money why not spend less of it using a better data store?

He also explicitly calls out the fact that record corruption/repair is intentional, and also explains that more of the defaults are bad. If the defaults are bad and that's known why keep them that way?

Simply put, he did a lot of damage control but honestly just made things worse, but never proved anything except that many of these claims are valid issues that make MongoDB the wrong tool for the job every time.. because we cannot trust it.

[NetOpWibby]

I'll take your word for it, I mostly skimmed and lost interest at the comments about trolls.

[duaneking]

The biggest issue I have with MongoDB is that it is not fully ACID compliant out of the box and for things like this you NEED that.

All the rest is just marketing the speed gains they get from not actually writing your data to disk, and marketing something MongoDB is built for as they prioritized the wrong things (Speed over data security). That's why everything operates from a queue. Its bad engineering. If the queue pops or writes fail there is absolutely no way to recover.

A Database should be stable and reliable as speed means nothing if the data is corrupted.