| HN Mirror

> These were private conversations, professional to professional, not conversations in the context of their sale. Maybe there is confirmation bias, but they could have just as easily said "Mongo was a piece of crap, we replaced it, it took a lot of engineering hours."

First, word gets around, "professional to professional" or not. Second, yes, people will subconsciously shift the blame to whatever they feel the least responsibility and/or enthusiasm for (aka "confirmation bias"). It's hard to find people who are sufficiently secure to even admit such errors to themselves, much less their colleagues, whom they want to think highly of them. Large doses of confirmation biases and other significant misconceptions that lead people to genuinely believe that their "shit doesn't stink", as it were, would definitely help whilst closing a multi-million dollar.

I've found that most of the technical choices that people make are simple fashion statements unless the technical limitations strictly disallow it (i.e., there is only one solution capable of providing a workable outcome). Software "engineers" and "architects" lie to themselves to justify whatever makes them feel more special and important. You don't have to look very far to see this in action (see: anyone claiming MongoDB was a good decision outside of a very unique or limited use case).

>All of the complaints I've seen against Mongo are from people who read Aphyr's blog from their SQL High Horse and say "ha, look at those dirty Mongo peasants, can't you see that one in every ten million reads are inconsistent under high load? Why would anyone use this crap?"

Please be assured that I read "Aphyr's blog" only when it hits an aggregator or when it comes up in a Google search. I haven't read his post on Mongo and edge cases where it may lose a write are of minimal relevance to my dislike for it (though this isn't something to trivialize in a database).

> Use it in production, even under significant load, and you realize that sure you might hit a snag every once in a while, but its tolerable. It works fine. Its not trash. Its adequate. Understand the problem you're trying to solve. Understand Mongo's limitations.

Yeah, I mean, I'm leaving a caveat for the 1% of cases where people do understand their workload and Mongo was the stronger fit for whatever weird edge case is in play.

But in all the cases I've seen Mongo deployed, it absolutely has been a very straightforward matter of "SQL is old and crusty, JSON is new and neato and it doesn't make us think about the structure of our data before we start spraying random values all over the place so let's use that! Woohoo!"

If we saw more MongoDB deployments that were strictly replacing EAV tables, the argument that people generally are using MongoDB for some legitimate technical function would be a lot stronger. But per usual, people are first, cargo-culting, and second, deploying something that trades the upfront effort of developing a schema with the not-so-distant development disaster that surely awaits those who refuse to plan their schemas.

You're right that Mongo doesn't just spontaneously combust, and I personally haven't contested that (I'm not the guy you originally replied to). I administer multiple Mongo clusters at $DAY_JOB and if left alone, they don't cause much fuss. But that is not the same thing as Mongo being a great engineering decision.