6 ms·

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.

Goopplesoft 9y ago
I can easily think of a few good reasons (it is actually a pretty good database for the right use-cases). Can you actually not find a good reason or are you just continuing the exaggerating echo chamber around mongodb's earlier failures for 'points'? Plus this has very little to do with the article which is a very very well done technical analysis of different solutions with very little opining.
- overcast 9y ago
  I mean, the JSON support in PostgreSQL is pretty freaking awesome now. Beyond the sharding, what are your few good reasons?
  - CodesInChaos 9y ago
    One thing I'd like to see in postgres is support for a superset of json, such as timestamps or binary data inside a json document. Replication and failover don't look so great in postgres either.
    - hiram112 9y ago
      Whenever I store binary data as text, I just base64 encode it and convert on the client.
- larrykwg 9y ago
  I think you baiting a rant, I count myself among the myriad developers who had to learn it the hard way to never use mongo. 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.
wyldfire 9y ago
I used it once when it first came out just to kick the tires. 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.
- skywhopper 9y ago
  Yeah, agreed. It does have a much better API than other JSON document stores I've tried. For the right use case, it would be fine.
013a 9y ago
*Today. The thing you're forgetting is that Mongo was actually somewhat novel at the time it was released. I've heard at least two stories of engineering teams who felt that their specific product couldn't have scaled the way it did and they wouldn't here today without Mongo, for whatever reason. I've heard the words "it was the best engineering decision we ever made" from one team who's company ended up selling for 8 figures. 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.
- user5994461 9y ago
  MongoDB doesn't scale. Write are handled by a single node.
  - gaius 9y ago
    No, it's web scale.
    - user5994461 9y ago
      It's not webscale if there is only one node doing all the work.
  - weddpros 9y ago
    a single node per shard will handle writes. If you have 20 shards, that's 20x more writes than a single node...
- cookiecaper 9y ago
  > I've heard at least two stories of engineering teams who felt that their specific product couldn't have scaled the way it did and they wouldn't here today without Mongo, for whatever reason. I've heard the words "it was the best engineering decision we ever made" from one team who's company ended up selling for 8 figures. 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.
dang 9y ago
Maybe so, but please don't post unsubstantive comments to HN, or rant here in flamebaity ways. 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.
SkyPuncher 9y ago
On the contrary, It's great when you have relatively unformed data. 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.

Goopplesoft 9y ago

I can easily think of a few good reasons (it is actually a pretty good database for the right use-cases). Can you actually not find a good reason or are you just continuing the exaggerating echo chamber around mongodb's earlier failures for 'points'? Plus this has very little to do with the article which is a very very well done technical analysis of different solutions with very little opining.

overcast 9y ago
I mean, the JSON support in PostgreSQL is pretty freaking awesome now. Beyond the sharding, what are your few good reasons?
- CodesInChaos 9y ago
  One thing I'd like to see in postgres is support for a superset of json, such as timestamps or binary data inside a json document. Replication and failover don't look so great in postgres either.
  - hiram112 9y ago
    Whenever I store binary data as text, I just base64 encode it and convert on the client.
larrykwg 9y ago
I think you baiting a rant, I count myself among the myriad developers who had to learn it the hard way to never use mongo. 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.

wyldfire 9y ago

I used it once when it first came out just to kick the tires. 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.

skywhopper 9y ago
Yeah, agreed. It does have a much better API than other JSON document stores I've tried. For the right use case, it would be fine.

013a 9y ago

*Today. The thing you're forgetting is that Mongo was actually somewhat novel at the time it was released. I've heard at least two stories of engineering teams who felt that their specific product couldn't have scaled the way it did and they wouldn't here today without Mongo, for whatever reason. I've heard the words "it was the best engineering decision we ever made" from one team who's company ended up selling for 8 figures. 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.

user5994461 9y ago
MongoDB doesn't scale. Write are handled by a single node.
- gaius 9y ago
  No, it's web scale.
  - user5994461 9y ago
    It's not webscale if there is only one node doing all the work.
- weddpros 9y ago
  a single node per shard will handle writes. If you have 20 shards, that's 20x more writes than a single node...
cookiecaper 9y ago
> I've heard at least two stories of engineering teams who felt that their specific product couldn't have scaled the way it did and they wouldn't here today without Mongo, for whatever reason. I've heard the words "it was the best engineering decision we ever made" from one team who's company ended up selling for 8 figures. 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.

dang 9y ago

Maybe so, but please don't post unsubstantive comments to HN, or rant here in flamebaity ways. 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.

SkyPuncher 9y ago

On the contrary, It's great when you have relatively unformed data. 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.