Guide to MongoDB for startups

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

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

This. http://hackingdistributed.com/2013/01/29/mongo-ft/

Also this. http://nyeggen.com/blog/2013/10/18/the-genius-and-folly-of-m...

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

As mkohlmyr mentions, it is unfortunate that MongoDB is offhandedly dismissed, however by the second paragraph of the linked article you have to appreciate how such hostility comes about.

But what is it that SQL databases could not solve which lead to the evolution of NoSql databases...{some "big data" changes to the world}...Which means processing huge amount of data. Which SQL databases were never designed for.

Firstly, specialized data storage and retrieval, including unstructured or document oriented, existed long before SQL did. Your filesystem is just such a system. Everything old is new again.

And secondly, a citation is required for the SQL databases "were never designed for" huge amounts of data claim. To start with, a definition of huge is necessary to make such a claim. 1GB? 1TB? 100TB? There are SQL solutions that work with all of those with ease. Many of the largest databases on the planet are humming away on SQL systems right now. SQL is abstract from the underlying platform, so if you have a cluster of 100 machines each in front of 1000 storage arrays each in front of 100 SSDs, it doesn't suddenly become "NoSQL".

SQL databases are generalized solutions. They generally do not solve specific, individual problems as well as precisely engineered solutions, which is why giant companies like Google, with extremely precise needs (e.g. index the web) have solutions that do a much better job for their purposes. Does that apply to your needs at all, though? Are you looking at your specific requirements, engineering precise storage and retrieval that is optimal? Probably not. Saying "MongoDB is under the umbrella of NoSQL, and NoSQL also kind of encompasses highly specialized solutions from industry leaders, so it will work for my startups contacts databases" is very, very poor, misleading reasoning. But we see it all of the time on HN in regards to solutions like mongodb. Which again is how you get responses that might seem hostile.