The lead in seriously harms the technical credibility of the rest of the entry.
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.
>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
Actually, I've had to deal with that first hand. It gets particularly nasty when multiple languages with varying type-tightness interact with the same data.
It's nice to hear someone else put this into words.
Why does business have to be built on dishonesty?
People get burned when they assume honesty and find that counterparties are dishonest. It's harder to get burned if you go into business or other intellectual relationships without expecting honesty. And I think, push come to shove, many founders will do what is necessary (no matter how unscrupulous) to keep their startup alive or to ensure the big payday, even if it comes at the price of turning back on promises or contracts with customers
I recommend you read http://www.zerohedge.com/node/13972 (the Conflicts/"Full Disclosure" Policy for zerohedge.com) as I think it captures the point very well.
'If you honestly say: "This is good with <product>, this is bad with <product>".'
In order to evaluate the veracity of the claim, you have to try the product. And if you have to pay money to try the product to verify the claim, then it's unclear as to how many people will actually bother to verify. If you price it high enough that the number of people is zero, then you could say whatever you want without others knowing if you are being honest.