These are very basic, but one can see how a web developer familiar with JSON could catch on quickly to the syntax. One can also how dynamic and simple it is, as well as some immediate benefits of using Mongo.
Before looking at why one should use Mongo, it should first be noted that even Mongo recognizes it is not for everyone. Databases have their own characteristics and are generally tailored for certain purposes. A comment on StackOverflow gives a quick look at why they use different databases.
The two main reasons one wouldn’t use Mongo is if there a lot of writes to the database or there is a lack of understanding of how durability is handled. As the article mentions, “a single mongod process can only process one write at a time, and issues a server level read/write lock while it’s doing so,” thus, writes can queue up and stall the server. Setting up replicas or sharding can mostly work around the issue, which is also the solution to durability. Mongo isn’t meant for single server durability, hence the need for replicating and sharding. Yet, there are some who claim that one should always use Mongo.
There are a number of reasons one would use Mongo. Perhaps the main reason is how well it meets the demands of web applications–scalability and replication alone are key advantages. Some use Mongo for its simplicity, sharding capabilities, and because it was built around storing files in the database. David Mitton wrote a thorough and well balanced article on why they switched to Mongo for Server Density, a program that monitors their servers. Their main reasons were: it’s easy to install, works with PHP, can be easily replicated, has automated sharding, and has good documentation.
There are more in-depth examples online as well as great documentation, even an online console on their home page for trying it out. No matter how much of a SQL traditionalist you may be, Mongo DB has great advantages that may be your best fit.