Really, the #1 reason to use MongoDB (if you're me, anyway) is to save development time associated with making your relational schema start small and change as your new app progresses. I feel a smug sense of joy every time I add a field somewhere, or delete another, or create some kind of nested document. It's taken me a while to really understand how many compromises I used to make because changing schemas is a pain in the ass.<p>Simplified queries, though, are a knock against mongo. Joins are great and I would like to do joins on my Mongo documents, but I end up having to replicate a lot of that in code. Sure it's nice that a document can be more complex and you don't spend a lot of time moving things into tables that are really part of the same record. It's nice because it's not <i>forced</i>, though, not because keeping data in different tables is always the wrong way to do things.
Three warnings when using mongodb. None of these are enough to say not to use it, but they're things you need to watch out for:<p>1. Don't run javascript on a production db node. db.eval locks the node it's running on until it finishes, so the performance of that node will go down the tubes. Mapreduce is less bad in this regard because it does yield, but it does so too infrequently. If you want to use mongo's built-in javascript interpreter for anything other than development and administration, set up a slave to run your scripts on.<p>2. Don't use 1.6.1. If you're using 1.6.1 right now, upgrade to 1.6.2. 1.6.1 has a nasty crashing bug that had my mongo node going down about once a day and not coming up without running --repair.<p>3. Evaluate how much data loss costs you. Mongo stages writes in memory, and so if the db crashes hard it's likely that there will be some data that hasn't made it to disk yet. If you're building a social network the cost of some potential data loss is probably much less than the savings in hardare, admin costs, development costs, etc. But if you're a payment processor or a gambling site, stick with postgres.
4) For web apps at least, it's nice to get data back in json format that you can give to the browser immediately without having to build your own json object each time. MongoDB saves you development time at every level. Add to the fact that it is easy to horizontally scale.<p>I'm using mongodb right now and the synergy between jquery - node.js - mongodb is simply amazing.
I like the idea of Mongo and have read about it but my relational mind can not be unwrapped. Maybe I am trying to complicate things too much. In that example if you have multiple people attending one event and you want to update the event name, do you have to go through all the people and all their events and update each one? Seems like that would be a lot of work, unless there is a way to query for that type of thing? And if there is a query, is it efficient? Seems like behind the scenes mongo would just be iterating through the users, but I'm sure there is more to it than that.
The reason you don't keep files in your database is that file systems are much better at handling files. Faster, more efficient, basically all the reasons that a single-purpose layer tends to be faster than a general-purpose layer.<p>Databases are much better at handling discrete data than file systems - that's what they are built for. Sure, I could keep my data in a bunch of little files, but that doesn't work as well.<p>(MS SQL has a feature where you "store" the file in the database, but the db writes the file to the filesystem, and just maintains a pointer to the actual file - not a bad hybrid)<p>I don't know how well GridFS stacks up (it is on my todo list), although I do like the idea of replication and sharding being built in. My gut (which has been wrong before) says that it is good for websites, not so good for general storage.<p>I use MongoDB for the same reason as mrkurt: prototyping new schemas is a breeze. I still find myself reaching for the old RDBMS toolbox as things move along, grow, and stabilize. Sometimes, a JOIN _is_ the right tool for the job.
To my (limited, I admit) knowledge of databases every one of these reasons was a reason to use CouchDB as well.<p>When the author got to the real arguments, he kept comparing MongoDB to SQL databases and the jab at CouchDB (and the other non-relational databases) seemed without merit to me.<p>I'm sure there are good reasons to use mongo over couch but I don't think they're the ones listed here.
4) You're using a 64-bit OS. <a href="http://blog.mongodb.org/post/137788967/32-bit-limitations" rel="nofollow">http://blog.mongodb.org/post/137788967/32-bit-limitations</a>
MongoDB is elegant and remarkably powerful. Every developer should run through the excellent getting started tutorial they have for it, as it really is eye opening.<p><a href="http://www.mongodb.org/display/DOCS/Tutorial" rel="nofollow">http://www.mongodb.org/display/DOCS/Tutorial</a><p>However I have to respectfully disagree on the "Simple queries" bit. The SQL example given is kind of terrible, however how about-<p>SELECT * FROM users WHERE id IN (SELECT user_id FROM events WHERE published_at IS NOT NULL)<p>or<p>SELECT * FROM users WHERE EXISTS (SELECT 1 FROM events WHERE published_at IS NOT AND user_id = users.id)<p><i>(Never use group by as a surrogate for IN/EXISTS. It forces the server to do a lot of unnecessary work)</i><p>Is that really unintuitive? Perhaps it's just acclimation, but I find those incredible easy to grep, with the MongoDB example being a variant of the same thing.<p>Of course that's just for very basic queries. Aggregations in MongoDB are far from intuitive (<a href="http://browsertoolkit.com/fault-tolerance.png" rel="nofollow">http://browsertoolkit.com/fault-tolerance.png</a>).