Ultimately most of the technical differences boil down to a single tradeoff between performance and reliability.

In some use cases, you have many transactions against a data store that won't be modified once it is set. In a case like that, mongodb is acceptable.

In other use cases, you have more complicated transactions involving lots of separate logical units. For example, lets say you are building an inventory and order management system. Someone wants to buy a widget. You need to reduce the widget inventory and push it into a customer's order, essentially an "Atomic" operation. AFAICT there's no "simple" data model under which MongoDB can give you atomicity.

In order to make a decision, the best bet is to figure out those requirements and just try one that fits the bill.

SQL databases are strongly typed and extremely good at enforcing consistency, whether you want them to or not. They are quite good at preventing many classes of bad data from being recorded in the first place, and allow you to do some types of low level data manipulation (joining datasets, eliminating duplicates, finding mins and maxes, etc) extremely efficiently.

NoSQL, on the other hand, is weakly typed and makes few if any attempts to validate your data, pushing that responsibility back onto you. They are very well suited to storing inherently inconsistent data (which, as a corollary, makes them very good for prototyping, when your data model is rapidly changing and growing). They also allow you to link much larger datasets into a 'document' which is retrieved as a unit with no extra computation.

So it mostly boils down to what kind of data you want to store. If you find yourself almost exclusively saying things like "All users have a username that is a string" or "I want to be able to find all products that cost less than $20" then you're probably looking for a traditional SQL database. If, on the other hand, you find yourself saying "some products have a width and height, but some just have a height, and a few have a volume instead" or "I want to be able to add custom fields to products on the fly" or "I never want to see purchases on their own, I always want to see them joined to the user that bought them" then you should probably consider a NoSQL solution.