Ask HN: Why use MongoDB?

What language are you writing your project(s) in?<p>If you are using Node you should use Mongoose and then you may see why some people love Mongo. Complex queries and joins (not technically called joins I guess) are incredibly easy to accomplish with that module[1]. Personally, I have migrated back to MySQL since I was unable to convince my colleagues that Mongo would last long-term and frankly I am not 100% confident either for the kind of business applications that we need[2].<p>[1]: <a href="http://mongoosejs.com/docs/populate.html" rel="nofollow">http:&#x2F;&#x2F;mongoosejs.com&#x2F;docs&#x2F;populate.html</a><p>[2]: payment processing industry handling billions of records

I&#x27;ve found it useful in storing and querying JSON documents. Basically, scraping an API (for me it was an OpenTripPlanner instance I had set up) and then being able to query any property in the data very easily.<p>But I didn&#x27;t use joins, nor was this anywhere near a production server. From my understanding, if you have a heavy requirement for joins then you just shouldn&#x27;t be using MongoDB in the first place. It isn&#x27;t a traditional relational database.

Our enterprise on-premise software package runs on Mongo, before it used to run on relational dbmses. Here&#x27;s why we changed:<p>- flexible document schema reduces migration complexity greatly, really important when we have our software deployed on many customers sites. - flexible schema is also important to our product because we support custom forms and fields. - the ability to store and search nested data - replication is easy to setup - easy to maintain, good export formats - no dependence on customer&#x27;s DBAs - no more frustrating explain-plan debugging of underperformant joins - text search (simple yet useful) - regex support - fast, up to 3x faster than SQL based engines for our use cases. - works well as a cache - decent also as a work queue with tailable capped collections.<p>Our biggest complain: the lack of transactions combined with data denormalization pitfalls is a PITA to work around in code.<p>Overall just a great db for when you need a flexible schema.

I just use Mongo as a big JSON &#x2F; BSON storage locker for node&#x2F;express stuff I&#x27;m learning. The apps all involve DOM manipulation and using HTML client API&#x27;s where div id&#x27;s and their positional data are stored as JSON&#x2F;BSON in Mongo ( then looped through and pulled back out when the user wants them ). Mongo seem really convenient for this kind of thing. I&#x27;ve done one similar project with PHP&#x2F;MYSQL before and the workflow seemed a bit more &#x27;heavy&#x27; compared to Mongo whichs thus far feels a bit more in alignment with this work style( I&#x27;m also using node&#x2F;express which is a bit complimentary ). So I guess my comment is more validation that its good for making small toys. Ha!

I would think it&#x27;s useful for any kind of data where it&#x27;s &quot;write once, then read only&quot; and there&#x27;s a standard sequence (key) you&#x27;ll use for almost every query. A blog, for example, or a twitter-type feed. In those cases, you&#x27;re not doing complicated interactions with the data, just &quot;SELECT&quot; everything in order and display it. In those kinds of applications, consistency and atomicity doesn&#x27;t matter much, and a NoSQL database might give you lower latency.

You should use the DB you need. Sometimes SQL is best, sometimes nosql. For me, the prime reason to use mongo is if I have data that I cannot structure before hand.