Hacker News Reader

Comment by mkohlmyr | Hacker News Reader

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.

View on HN

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

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-wi... and it's from 2011

It's a lot of time for a software project

It is a long time, but little has changed regarding the issues shown in that talk.

Do you think it is MongoDB problem or all NoSQL dbs has the some problem?

Every DBMS comes with its own set of special problems. Most people only find out about the truly tricky ones once they have deployed a database in production (i.e. when it is too late to decide your needs are actually not served all that well by what you chose).

Once a DBMS like MongoDB gets popular, then people uncover some of its failings and write about them...which is great because it means you don't have to discover the same things the hard way. But it's a drag too because there's no database system that everyone agrees is adequate (much less ideal) for every application.

Other NoSQL solutions were not marketed as a replacement for relational databases. MongoDB might be better now,but you cant take managers for idiots an expect them to buy into your product again. Right now MongoDB only lives because of javascript and nodejs ,since nodejs sucks big time with anything that is not MongoDB,library and driver wise.

Absolute rubbish. The node Postgres driver is excellent and has performed flawlessly for us.

CouchDB is a total joy to use, and because it's just REST, you don't even need a driver.

There's a neat helper library in nano, but that just constructs requests for you.

Absolute poppycock. Redis, Riak, Postgres, MSSQL drivers all work quite well.

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

[2] http://www.mongodb.org/about/production-deployments/

[3] http://www.sarahmei.com/blog/2013/11/11/why-you-should-never...

[4] http://www.aaronstannard.com/post/2013/12/19/The-Taxonomy-of...

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.

> 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.

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.

> 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.

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.

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.

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.

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.

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.

Slower than Postgres ... ha.

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.

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.

what is mongodb for then. what is the use case where it is better than the other tools?

> 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.

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.

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. ;)

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.

> 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.

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.

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.

> 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.

I've used MongoDB in production for 3 years or so and I've had nothing but problems. There's nothing like paying 10gen $100K for support and having them tell you they have no idea why your database isn't working.

Just because your small scale system is running okay doesn't mean MongoDB is great, just that it's okay for your application.

Reply on news.ycombinator.com