Sorry to add another answer but none of the answers here are very satisfactory. This answer is specific to MongoDB (as opposed to the vast array of other data storage options out there which are not relational databases).
Update (July 2020)
Every now and then this answer gets a vote and I get a pang of guilt because I've felt for a while it has grown into a stale answer. For one thing, MongoDB supports multi-document transactions now which throws into question a fair number of the points I've brought up. I haven't used it for performance in depth since they added these transactions so I cannot comment on that.
Furthermore, I have recently been working with unstructured data and the schemaless property of MongoDB has been more of a benefit than the below answer might suggest. For example, I am working with test result data generated by a testing & execution solution. The test cases themselves (and thus the different result columns) are created by the end user. MongoDB allowed me to store the free-form test results, in a way that is searchable, without needing a strict schema. I will re-emphasize my point on migration though. Every time the users make a change to their test cases the tools they are using to analyze their results also has to change.
As an alternative, SQL based storage engines have strengthened support for free-form columns such as Postgres' JSONB data type or MySQL's JSON data type.
Take Away: Today, the differences between mongodb and an SQL database feel more and more like the differences between Java & C# or maybe Node & Java. Both have their zealots that will feel the decision is obvious. They both obviously do things differently under the hood. However, at the end of the day its hard to declare either one superior or even to identify broad situations that favor either one.
If you are struggling to make this choice then pick the one that most appeals to you. Keep in mind that any data solution is likely to need to be revisited and rewritten continuously as your application scales up. By then you will understand your storage needs more and will likely be looking for a very tailored critical section / use case.
- MongoDB has a lower latency per query & spends less CPU time per query because it is doing a lot less work (e.g. no joins, transactions). As a result, it can handle a higher load in terms of queries per second and is thus often used if you have a massive # of users.
- MongoDB is easier to shard (use in a cluster) because it doesn't have to worry about transactions and consistency.
- MongoDB has a faster write speed because it does not have to worry about transactions or rollbacks (and thus does not have to worry about locking).
- MongoDB does not have a schema in case you have a special use case that can take advantage of that.
- MongoDB does not support transactions. This is how it obtains most of its benefits.
- In general, MongoDB creates more work (e.g. more CPU cost) for the client server. For example, to join data one has to issue multiple queries and do the join on the client.
- Even here in 2017 there is less tooling support for MongoDB than there is for relational databases simply because it is newer. There are also fewer MongoDB experts than their relational counterparts.
Points Often Misunderstood:
- Both MongoDB and relational databases support indexing. Their query performance is similar in terms of executing large queries.
- MongoDB does not remove the need for migrations or more specifically, updating your existing data as your schema evolves. For example: If you have an application that relies on a users table to contain certain data, and you modify that table to contain different data (let's say you add a profile picture field), then you will still need to either:
- Write you application to handle objects for which this property is undefined OR
- Write a one-time migration to put in a default value for this property OR
- Write code to provide a default value at query time if this field is not present OR
- Handle the missing field in some other way