The MEAN Stack: MongoDB, ExpressJS, AngularJS and Node.js

Go have a look at the complex number implementation here: http://www.postgresql.org/docs/9.1/static/xtypes.html then come back and tell me that Postgres is "not a real programming language" (whatever that means these days).

I just noticed you said almost. Maybe this is the exceptional case you were thinking of :)

Most applications grow to the point that they have multiple database clients (it is a virtual inevitability).

Utilities that have to do something. Integration points. Etc.

In an ideal world these can all be completely tunneled through an API, but that is seldom the practice (different needs, different maintenance cycles, etc), whether in a RDBMS or a document model.

Above and beyond that, most applications see technical variations and evolutions of the things that contact it. Today you might be enamored with nodejs, tomorrow it's Go, and the next day it's noderust, etc. Having a technology-coupled surrogate for basic database functionality isn't a sustainable approach.

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.

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.

Why does business have to be built on dishonesty?