schema-less. If you have a flexible schema, this is ideal for a document store like
MongoDB. This is difficult to implement in a performant manner in RDBMS
ease of scale-out. Scale reads by using replica sets. Scale writes by using sharding (auto balancing). Just fire up another machine and away you go. Adding more machines = adding more RAM over which to distribute your working set.
cost. Depends on which RDBMS of course, but MongoDB is free and can run on Linux, ideal for running on cheaper commodity kit.
you can choose what level of consistency you want depending on the value of the data (e.g. faster performance = fire and forget inserts to MongoDB, slower performance = wait til insert has been replicated to multiple nodes before returning)
Cons:
Data size in MongoDB is typically higher due to e.g. each document has field names stored it
less flexibity with querying (e.g. no JOINs)
no support for transactions - certain atomic operations are supported, at a single document level
at the moment Map/Reduce (e.g. to do aggregations/data analysis) is OK, but not blisteringly fast. So if that's required, something like Hadoop may need to be added into the mix
less up to date information available/fast evolving product
I recently blogged my thoughts on MongoDB as someone coming from SQL Server background, so you might be interested in that (above are just some of the main points).
If you're looking for a "Is MongoDB better than RDBMS" answer - then IMHO there is no answer. NoSQL technologies like MongoDB provide an alternative, that complements RDBMS technologies. One may be better suited to a particular purpose than the other, so it's all about making a call on what is best for you for a given requirement.