10 ms·

I find it somewhat depressing that the first comments on any post about MongoDB generally seem to be short, disparaging and dismissive without offering much if

I find it somewhat depressing that the first comments on any post about MongoDB generally seem to be short, disparaging and dismissive without offering much if any substance. We use MongoDB in production, processing millions of new records every month and it works great. Our data has differing and evolving schemas and can be used as JavaScript objects or python dictionaries with little effort. It works and performs well for us and our use case. I'd be delighted to find out what these nay-sayers are doing that MongoDB must fail so incredibly at for them to have such strong negative opinions. I'm not speaking only to the existing comments on this post but the general theme of past MongoDB submissions.

crusso 13y ago
I've only casually used MongoDB, but the articles about companies switching from it to other solutions (I've seen at least two about companies switching from Mongo to Riak) have kept me wary of it. Personally, my 10k foot impression has been that MongoDB is really easy to get started with, has some cool features, and is fun to use... but then in production it has serious issues that are fundamentally unworkable. Until I see a series of: "Here is what was wrong with MongoDB and how we fixed it" articles floating around along with a number of endorsements - I'm probably going to keep that 10k foot view. I could easily be criticized for not digging in to Mongo's problems myself to learn exactly what they are and whether or not they are still an issue, but life is too short and there are too many other things to do.
RyanZAG 13y ago
It's because mongodb just isn't as good at queries as a relational db, while also not offering the scalability benefits that other nosql databases do. Also the attitude that mongodb takes towards data - namely, convenience and performance first, data safety second - is very incompatible with most uses for a database.
- deleted 13y ago
  [deleted]
wiremine 13y ago
> It works and performs well for us and our use case. 100% agree. I think it's become cool to knock MongoDB, just because it is MongoDB. It isn't a silver bullet, and its use cases are more limited than RDBMs. But if you know what you're doing, it has some great applications.
- dasil003 13y ago
  Mongo achieved success because of marketing overselling its capabilities. Now they are dying by the same sword, and rightly so IMO because databases are not something where marketability, ease-of-use and fashion should trump solid engineering.
- Pacabel 13y ago
  I'm sorry, this is absurd. You truly think that so many experienced database professionals and software developers speak out about the dangers of using it solely to be "cool"? You really don't think it has anything to do with the numerous serious technical deficiencies it suffers from? (Read some of the other comments for this submission if you really do need more details about these problems.) When it comes to databases, fooling around just isn't an option. If a given database technology has flaws, then those flaws need to be widely known. And this isn't done to be "cool". This is done because the safety and integrity of data are of the utmost importance when working with database systems, and it's absolutely critical to know about anything that may cause problems.
  - wiremine 13y ago
    > You truly think that so many experienced database professionals and software developers speak out about the dangers of using it solely to be "cool"? Yes, I do, actually. I see a TON of out-of-date commentary on places like HN, or just stuff that is factually incorrectly. I have used MongoDB in production for 3+ years, and it hasn't caused any problems. I will say the out-of-the-box set up isn't what you want in production.
    - nasalgoat 13y ago
thisishugo 13y ago
There was a spate of high profile "why we moved from MongoDB to $other_database" articles a year or so ago of startups getting burned when they realised that the all-signing all-dancing cure-all database they (thought they) had been sold, in fact wasn't. The issues encountered ranged from MongoDB failing to scale out as easily as promised, to significant loss of data. There was also some backlash because MongoDB didn't (and perhaps still doesn't) persist data to disk when it acknowledged it as received[0]. A general perception grew, rightly or not, than MongoDB was being marketed by 10Gen[1] over and above its capabilities. Then the actual message of "MongoDB is not a drop-in replacement for traditional RDBMSs like PostgreSQL and MySQL, and is not the ideal solution to every problem" has been filtered down to "MongoDB is a terrible product with no use cases whatsoever." Such is the effect of the HN echo chamber. Much like PHP, MongoDB is now simply a product that you cannot say anything good about on HN, even if you are in fact finding it an effective tool for your use case in spite of its shortcomings. [0] Cynically, because they were trying to win benchmarks. Less cynically, because the use case was semi-ephemeral data where possibly losing some data is acceptable. [1] Now also called MongoDB
- raverbashing 13y ago
  Yes, I agree, however MongoDB is evolving This is probably what raised awareness of the issues of MongoDB http://www.slideshare.net/emiltamas/scaling-with-mongo-db-with-notes http://www.slideshare.net/emiltamas/scaling-with-mongo-db-wi... and it's from 2011 It's a lot of time for a software project
  - ricardobeat 13y ago
    It is a long time, but little has changed regarding the issues shown in that talk.
- dougcorrea 13y ago
  Do you think it is MongoDB problem or all NoSQL dbs has the some problem?
  - jzwinck 13y ago
rwallace 13y ago
Well, I'll explain why I'm a naysayer on NoSQL. I will grant that "don't use NoSQL" isn't the correct advice in absolutely all cases. Once in a blue moon there is a case where it's the best solution, and if you say you have one of those cases, fair enough, I'll take your word for it. But the vast majority of people who use NoSQL should be using a relational database instead. And the consequences of using NoSQL where you shouldn't, can be very bad indeed. (If your data gets messed up, it's not like a bug that can be put right just by fixing your code.) So I will stand by "don't use NoSQL" as general advice. If you're really sure you know what you're doing, if you have sufficient expertise on databases and understanding of the present and future characteristics of your workload to be certain you're an exception, fine; but then you don't need general advice in the first place.
yukichan 13y ago
Aphyr has thoroughly explained what is wrong with MongoDB[1]. I'm quite sure that things aren't probably as swell with your tech stack you might imagine. A commenter here has in the past demonstrated how to cause someone using MongoDB data problems by sending too much information too quickly for MongoDB to handle in a targeted way although I can't find the link to it now. I have been wanting to try it myself to see if I could do it too. Firebase uses MongoDB[2]: "Firebase stores all its data in MongoDB which offers the built-in capability for apps to scale automatically and gives each piece of data its own unique URL stored in JSON documents." I was going to see if I can get achieve data consistency problems there for my own firebase app. Also posts that malign MongoDB frequently make it to the home page [3][4]. [1] http://aphyr.com/posts/284-call-me-maybe-mongodb http://aphyr.com/posts/284-call-me-maybe-mongodb [2] http://www.mongodb.org/about/production-deployments/ http://www.mongodb.org/about/production-deployments/ [3] http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/ http://www.sarahmei.com/blog/2013/11/11/why-you-should-never... [4] http://www.aaronstannard.com/post/2013/12/19/The-Taxonomy-of-Terrible-Programmers.aspx http://www.aaronstannard.com/post/2013/12/19/The-Taxonomy-of...
- jasonmccay 13y ago
  Aphyr did the same "Call Me Maybe" posts for other databases as well, highlighting their shortcomings. MongoDB has issues, but other databases have their rough edges as well. It all depends on how you use them. For a group of people that know nothing but hammers, screwdrivers don't make much sense. This feels often what these "bash Mongo" arguments sound like. There is no silver bullet. Just flippin' understand the tool you are using and how to use it.
  - AlisdairO 13y ago
    > Just flippin' understand the tool you are using and how to use it. If people understand Mongo and its shortcomings, then fair enough. The thing is, those shortcomings are large and far-reaching, and the number of applications for which Mongo is a truly superior long-term choice are relatively few. It's my perception that when the hype around Mongo peaked there was an awful lot of ignorance surrounding the product - the current behaviour towards it is probably a reaction to that.
lucian1900 13y ago
That's because it really is a terrible database. It does absolutely nothing better than other popular databases. It's slower, less durable and has less features than Postgres, but also slower, less reliable and worse at sharding than Cassandra.
- jasonmccay 13y ago
  Slower than Postgres ... ha.
  - bitcrusher 13y ago
    You're kinda all over the place trying to defend MongoDB... So, what is your stake in it? You like it? You have a lot of customers on it and you want to validate your decision? I'm just curious, because by my tastes, MongoDB is an awful database. It's like the PHP of Databases. It seems like there are a lot of better choices out there especially in the last few years.
    - jasonmccay 13y ago
      Considering MongoDB has only been around for the "last few years", I think it is maturing well. You are certainly free to call it the PHP of Databases, but there are a lot of developers that have learned to use it and are quite happy with it. Seems like most on Hacker News spend more time telling them why they are stupid than actually understanding the tool. (Also, some guy by the name of Zuckerberg made a TON of money with PHP.) Also, the tool is still in its toddler years ... and it is constantly compared to tools that have been around years longer (PG/MySQL). Comparing it to other NoSQL databases is just as silly (Riak, Cassandra) because they are completely different, have different constraints and are solving different problems. There aren't better choices ... there are just different tools that are better for different jobs. It would be like looking at your toolbox and chunking everything but your saw or your hammer. Too many people are looking for the "technology to rule them all", but that doesn't (and shouldn't) exist.
      - AdrianRossouw 13y ago
mratzloff 13y ago
> We use MongoDB in production, processing millions of new records every month and it works great. It fails miserably in various ways when processing millions of new records per hour. On a very large scale MongoDB is unusable, but it is fine for problems 2-3 orders of magnitude smaller, so long as the data is not mission-critical.
- twic 13y ago
  One million new records a month is less than one new record a second. Ten million new records a month is almost four new records a second (slightly more than four if the month is February!). That is not a challenging level of performance for any database, relational or otherwise. It is indeed the millions-per-hour order of magnitude where things get interesting.
- jasonmccay 13y ago
  Man, I need to go break the news to our customers that are successfully inserting millions of documents per hour (and their apps running nicely ... probably an app you have used) to inform them that, in all reality, they are "failing miserably." They'd be shocked(!) at the news. ;)
meritt 13y ago
> Which means processing huge amount of data. Which SQL databases were never designed for. When an article opens with a statement like it's difficult to give it much credence at that point. Unfortunately, this ignorance is very common among the MongoDB crowd. Like your example? millions of new records every month? That's not a "huge amount of data". We're adding tens of millions new records each day, into mysql, and I would still consider our usage extremely intermediate if not amateur. MongoDB has many benefits, they've improved on numerous oversights and flaws in their initial design, and it's becoming better all the time. What I'd love to actually see change is the naive belief of MongoDB users that it's a new, unique or vastly superior solution.
- mkohlmyr 13y ago
  Neither of the comments nor mine were specifically in relation to this particular article though. Since I'm taking a few hits on "millions" I should perhaps clarify it's more like "hundreds of millions". Still obviously not a gigantic amount but certainly enough for me to be able to say that it is functional enough and robust enough as a database that a lot of the negativity is if not unwarranted, then at least excessive.
gaius 13y ago
I find it somewhat depressing that the first comments on any post about MongoDB generally seem to be short, disparaging and dismissive without offering much if any substance There's just not much to say tho'. If this were an aviation site and people kept posting about how piston engines were the future because jets "don't scale to large aircraft" and "were never designed for long journeys" how would you argue against that? There would just be no point. I'll say this tho': in 1969 IBM released a NoSQL product called IMS, which was designed to handle the BOM for the Saturn project. IMS has been continuously developed since then. Have a look at it and what it can do, then look again at MongoDB, which is - genuinely - about 40 years behind the state-of-the-art. Then understand why experienced database guys* can't be bothered to debunk it any more. * my own stats: 50+Tb in Oracle with 800G changes/day, replicated to 2 other identical databases over WAN links. 2+Tb in MySQL. 10,000 commits/sec + 50,000 reads/sec on Oracle. 99.99% uptime on all of this. When people tell me "SQL databases" don't scale or aren't reliable, I laugh. And then ignore them.
nasalgoat 13y ago
I've also used MongoDB in production, processing millions of new records per month, but the systems requirements to handle that load outstrip PostgreSQL by a magnitude of 10x. Also, the various gotchas involved with maintaining MongoDB at scale meant I spent most of my team's time chasing down esoteric problems instead of serving customers. But ultimately, trusting a database with decades of development behind it to handle something like a JOIN turns out to be a good idea. In my experience.

crusso 13y ago

I've only casually used MongoDB, but the articles about companies switching from it to other solutions (I've seen at least two about companies switching from Mongo to Riak) have kept me wary of it. Personally, my 10k foot impression has been that MongoDB is really easy to get started with, has some cool features, and is fun to use... but then in production it has serious issues that are fundamentally unworkable. Until I see a series of: "Here is what was wrong with MongoDB and how we fixed it" articles floating around along with a number of endorsements - I'm probably going to keep that 10k foot view. I could easily be criticized for not digging in to Mongo's problems myself to learn exactly what they are and whether or not they are still an issue, but life is too short and there are too many other things to do.

RyanZAG 13y ago

It's because mongodb just isn't as good at queries as a relational db, while also not offering the scalability benefits that other nosql databases do. Also the attitude that mongodb takes towards data - namely, convenience and performance first, data safety second - is very incompatible with most uses for a database.

deleted 13y ago
[deleted]

wiremine 13y ago

> It works and performs well for us and our use case. 100% agree. I think it's become cool to knock MongoDB, just because it is MongoDB. It isn't a silver bullet, and its use cases are more limited than RDBMs. But if you know what you're doing, it has some great applications.

dasil003 13y ago
Mongo achieved success because of marketing overselling its capabilities. Now they are dying by the same sword, and rightly so IMO because databases are not something where marketability, ease-of-use and fashion should trump solid engineering.
Pacabel 13y ago
I'm sorry, this is absurd. You truly think that so many experienced database professionals and software developers speak out about the dangers of using it solely to be "cool"? You really don't think it has anything to do with the numerous serious technical deficiencies it suffers from? (Read some of the other comments for this submission if you really do need more details about these problems.) When it comes to databases, fooling around just isn't an option. If a given database technology has flaws, then those flaws need to be widely known. And this isn't done to be "cool". This is done because the safety and integrity of data are of the utmost importance when working with database systems, and it's absolutely critical to know about anything that may cause problems.
- wiremine 13y ago
  > You truly think that so many experienced database professionals and software developers speak out about the dangers of using it solely to be "cool"? Yes, I do, actually. I see a TON of out-of-date commentary on places like HN, or just stuff that is factually incorrectly. I have used MongoDB in production for 3+ years, and it hasn't caused any problems. I will say the out-of-the-box set up isn't what you want in production.
  - nasalgoat 13y ago

thisishugo 13y ago

There was a spate of high profile "why we moved from MongoDB to $other_database" articles a year or so ago of startups getting burned when they realised that the all-signing all-dancing cure-all database they (thought they) had been sold, in fact wasn't. The issues encountered ranged from MongoDB failing to scale out as easily as promised, to significant loss of data. There was also some backlash because MongoDB didn't (and perhaps still doesn't) persist data to disk when it acknowledged it as received[0]. A general perception grew, rightly or not, than MongoDB was being marketed by 10Gen[1] over and above its capabilities. Then the actual message of "MongoDB is not a drop-in replacement for traditional RDBMSs like PostgreSQL and MySQL, and is not the ideal solution to every problem" has been filtered down to "MongoDB is a terrible product with no use cases whatsoever." Such is the effect of the HN echo chamber. Much like PHP, MongoDB is now simply a product that you cannot say anything good about on HN, even if you are in fact finding it an effective tool for your use case in spite of its shortcomings. [0] Cynically, because they were trying to win benchmarks. Less cynically, because the use case was semi-ephemeral data where possibly losing some data is acceptable. [1] Now also called MongoDB

raverbashing 13y ago
Yes, I agree, however MongoDB is evolving This is probably what raised awareness of the issues of MongoDB http://www.slideshare.net/emiltamas/scaling-with-mongo-db-with-notes http://www.slideshare.net/emiltamas/scaling-with-mongo-db-wi... and it's from 2011 It's a lot of time for a software project
- ricardobeat 13y ago
  It is a long time, but little has changed regarding the issues shown in that talk.
dougcorrea 13y ago
Do you think it is MongoDB problem or all NoSQL dbs has the some problem?
- jzwinck 13y ago

rwallace 13y ago

Well, I'll explain why I'm a naysayer on NoSQL. I will grant that "don't use NoSQL" isn't the correct advice in absolutely all cases. Once in a blue moon there is a case where it's the best solution, and if you say you have one of those cases, fair enough, I'll take your word for it. But the vast majority of people who use NoSQL should be using a relational database instead. And the consequences of using NoSQL where you shouldn't, can be very bad indeed. (If your data gets messed up, it's not like a bug that can be put right just by fixing your code.) So I will stand by "don't use NoSQL" as general advice. If you're really sure you know what you're doing, if you have sufficient expertise on databases and understanding of the present and future characteristics of your workload to be certain you're an exception, fine; but then you don't need general advice in the first place.

yukichan 13y ago

Aphyr has thoroughly explained what is wrong with MongoDB[1]. I'm quite sure that things aren't probably as swell with your tech stack you might imagine. A commenter here has in the past demonstrated how to cause someone using MongoDB data problems by sending too much information too quickly for MongoDB to handle in a targeted way although I can't find the link to it now. I have been wanting to try it myself to see if I could do it too. Firebase uses MongoDB[2]: "Firebase stores all its data in MongoDB which offers the built-in capability for apps to scale automatically and gives each piece of data its own unique URL stored in JSON documents." I was going to see if I can get achieve data consistency problems there for my own firebase app. Also posts that malign MongoDB frequently make it to the home page [3][4]. [1] http://aphyr.com/posts/284-call-me-maybe-mongodb http://aphyr.com/posts/284-call-me-maybe-mongodb [2] http://www.mongodb.org/about/production-deployments/ http://www.mongodb.org/about/production-deployments/ [3] http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/ http://www.sarahmei.com/blog/2013/11/11/why-you-should-never... [4] http://www.aaronstannard.com/post/2013/12/19/The-Taxonomy-of-Terrible-Programmers.aspx http://www.aaronstannard.com/post/2013/12/19/The-Taxonomy-of...

jasonmccay 13y ago
Aphyr did the same "Call Me Maybe" posts for other databases as well, highlighting their shortcomings. MongoDB has issues, but other databases have their rough edges as well. It all depends on how you use them. For a group of people that know nothing but hammers, screwdrivers don't make much sense. This feels often what these "bash Mongo" arguments sound like. There is no silver bullet. Just flippin' understand the tool you are using and how to use it.
- AlisdairO 13y ago
  > Just flippin' understand the tool you are using and how to use it. If people understand Mongo and its shortcomings, then fair enough. The thing is, those shortcomings are large and far-reaching, and the number of applications for which Mongo is a truly superior long-term choice are relatively few. It's my perception that when the hype around Mongo peaked there was an awful lot of ignorance surrounding the product - the current behaviour towards it is probably a reaction to that.

lucian1900 13y ago

That's because it really is a terrible database. It does absolutely nothing better than other popular databases. It's slower, less durable and has less features than Postgres, but also slower, less reliable and worse at sharding than Cassandra.

jasonmccay 13y ago
Slower than Postgres ... ha.
- bitcrusher 13y ago
  You're kinda all over the place trying to defend MongoDB... So, what is your stake in it? You like it? You have a lot of customers on it and you want to validate your decision? I'm just curious, because by my tastes, MongoDB is an awful database. It's like the PHP of Databases. It seems like there are a lot of better choices out there especially in the last few years.
  - jasonmccay 13y ago
    Considering MongoDB has only been around for the "last few years", I think it is maturing well. You are certainly free to call it the PHP of Databases, but there are a lot of developers that have learned to use it and are quite happy with it. Seems like most on Hacker News spend more time telling them why they are stupid than actually understanding the tool. (Also, some guy by the name of Zuckerberg made a TON of money with PHP.) Also, the tool is still in its toddler years ... and it is constantly compared to tools that have been around years longer (PG/MySQL). Comparing it to other NoSQL databases is just as silly (Riak, Cassandra) because they are completely different, have different constraints and are solving different problems. There aren't better choices ... there are just different tools that are better for different jobs. It would be like looking at your toolbox and chunking everything but your saw or your hammer. Too many people are looking for the "technology to rule them all", but that doesn't (and shouldn't) exist.
    - AdrianRossouw 13y ago

mratzloff 13y ago

> We use MongoDB in production, processing millions of new records every month and it works great. It fails miserably in various ways when processing millions of new records per hour. On a very large scale MongoDB is unusable, but it is fine for problems 2-3 orders of magnitude smaller, so long as the data is not mission-critical.

twic 13y ago
One million new records a month is less than one new record a second. Ten million new records a month is almost four new records a second (slightly more than four if the month is February!). That is not a challenging level of performance for any database, relational or otherwise. It is indeed the millions-per-hour order of magnitude where things get interesting.
jasonmccay 13y ago
Man, I need to go break the news to our customers that are successfully inserting millions of documents per hour (and their apps running nicely ... probably an app you have used) to inform them that, in all reality, they are "failing miserably." They'd be shocked(!) at the news. ;)

meritt 13y ago

> Which means processing huge amount of data. Which SQL databases were never designed for. When an article opens with a statement like it's difficult to give it much credence at that point. Unfortunately, this ignorance is very common among the MongoDB crowd. Like your example? millions of new records every month? That's not a "huge amount of data". We're adding tens of millions new records each day, into mysql, and I would still consider our usage extremely intermediate if not amateur. MongoDB has many benefits, they've improved on numerous oversights and flaws in their initial design, and it's becoming better all the time. What I'd love to actually see change is the naive belief of MongoDB users that it's a new, unique or vastly superior solution.

mkohlmyr 13y ago
Neither of the comments nor mine were specifically in relation to this particular article though. Since I'm taking a few hits on "millions" I should perhaps clarify it's more like "hundreds of millions". Still obviously not a gigantic amount but certainly enough for me to be able to say that it is functional enough and robust enough as a database that a lot of the negativity is if not unwarranted, then at least excessive.

gaius 13y ago

I find it somewhat depressing that the first comments on any post about MongoDB generally seem to be short, disparaging and dismissive without offering much if any substance There's just not much to say tho'. If this were an aviation site and people kept posting about how piston engines were the future because jets "don't scale to large aircraft" and "were never designed for long journeys" how would you argue against that? There would just be no point. I'll say this tho': in 1969 IBM released a NoSQL product called IMS, which was designed to handle the BOM for the Saturn project. IMS has been continuously developed since then. Have a look at it and what it can do, then look again at MongoDB, which is - genuinely - about 40 years behind the state-of-the-art. Then understand why experienced database guys* can't be bothered to debunk it any more. * my own stats: 50+Tb in Oracle with 800G changes/day, replicated to 2 other identical databases over WAN links. 2+Tb in MySQL. 10,000 commits/sec + 50,000 reads/sec on Oracle. 99.99% uptime on all of this. When people tell me "SQL databases" don't scale or aren't reliable, I laugh. And then ignore them.

nasalgoat 13y ago

I've also used MongoDB in production, processing millions of new records per month, but the systems requirements to handle that load outstrip PostgreSQL by a magnitude of 10x. Also, the various gotchas involved with maintaining MongoDB at scale meant I spent most of my team's time chasing down esoteric problems instead of serving customers. But ultimately, trusting a database with decades of development behind it to handle something like a JOIN turns out to be a good idea. In my experience.