There is absolutely no good reason for anyone to use MongoDB ever, its just such an amazingly rotten database that its astounding how much hype it generated.
We're looking for thoughtful comments. That doesn't require changing your views at all, just presenting them with more information, and an orientation to good conversation rather than venting.
You're being hyperbolic. Yes, there are so many better choices for databases out there. There are also many worse choices. Mongo is very hard to recommend nowadays, but unless you go in completely ignoring its problems its not like your company is going to go up in flames.
Do you expect to hear them say, "Yes, choosing MongoDB was a bad decision and our production infrastructure is currently on an unwieldy, slow, dangerous piece of crap" and then go on to sell the company for tens of millions of dollars?
Do you expect people to admit the real reason they're using MongoDB, which, in 99% of cases, is "we don't know how to use SQL and are really perturbed that anyone thinks we should have to learn"?
It is true that MongoDB only spontaneously combusts occasionally, but that doesn't mean the choice is of negligible importance.
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?" 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.
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.
Nope, my dislike of MongoDB the technology and distrust of 10gen/Mongo the company is 100% based on real-world experience.
By the way, one-in-ten-million means several times a day. And it was a LOT more frequent than that...
What a remarkably convenient API it had. NoSQL/"Document store" stuff was relatively new (to me, at least). Did the convenient API contribute to whatever design problems they had? No idea.
But if they had problems with durability then it really is all for naught. I didn't get beyond prototyping so I never saw whatever issues caused them to get so much ire.
I've head of a lot of logging (i.e. application logging) companies have great success with Mongo because they can store their entire client's set of data without need to know the schema ahead of time.
Replication and failover don't look so great in postgres either.
My point would be that there are no "right" use-cases, I pointed it out because the article was talking about a specific thing: as the article points out in the outlined scenario: "It’s clear now, that throughput for PostgreSQL and MongoDB now is almost the same before the spinlock performance degradation hits MongoDB."
So the article points out there is a significant performance degradation after a certain number of connections in MongoDB, such things won't surprise me anymore I'll add it to the heap of things wrong with MongoDB, thats why I was making the comment.
> "We’ve got so far that throughput of PostgreSQL and MongoDB is the same for read workloads. Is it surprising? Not at all - I’m going to show you, that under the hood all our databases use more or less the same data structures and the same approach to store documents."
I'd argue that there is no reason to use MongoDB because there are no use-cases other more mature databases won't be equally or better suited for. MongoDB is horrid, you won't know all its deficiencies when you get started with it, but over time you will come to despise it, it is really far away from being a mature database and I would advice anyone against using it for any task, and I'm not the only one who was burned using it and who adopted this attitude towards it.