Document databases are a passing fad, a backlash against the flaws in the currently available open source databases. These flaws have nothing to do with the relational model.<p>If there was an open source RDBMS that allowed instant/lazy schema migrations, direct map-reduce access to its data, was able to automatically partition and shard, and somehow magically had performant joins you would never see these document database come to be so popular. Document databases have no mathematical grounding analagous to the relational model; the reason is because they are a hackneyed application of the relational model that allows implemention to bleed even further into the model than current RDBMses do. For example, the fact a developer now will have to choose between "embedding" or joining documents together application side has absolutely <i>zero</i> different in terms of the true data model. The data model is unchanged in either scenario, it is just being <i>materialized</i> differently on disk for implementation issues.<p>Edit: To be clear, the way things <i>should</i> work is you should model your data as a normalized, clean model. Then, you should be able to annotate the data or provide alternative views that "embed" documents and so on to reduce cross-table joins. This is an optimization layer and the actual materialization of these views should be maintained by the database. It should be part of the query optimizer, and your joins should simply speed up once they can access the "embedded versions". The fact that you have to do this all manually and store the data yourself, and basically take on the role of the query optimizer as well, shows that we've traded C for assembly code in the db world with these document databases.<p>It's truly a sad state of affairs that peoples horrible experiences with whatever particular RDBMS they've used are causing them to react by using one of these document databases. Now, they've got a whole series of new problems. There is no free lunch until someone addresses some of the pain points like schema evolution in a way that doesn't sacrifice everything else.
I stopped reading when he said consistency is in your hands (with noSQL). Since you have to manage relationships, and doing so requires several round trips to the datastore, and generally doesn't involve transactions, what happens when inserts 1 and 2 succeed, but insert 3 fails? What happens if you crash before insert 3?
In high volume applications, these situations will arise and you will end up with inconsistent data. That doesn't prevent noSQL from being useful in some situations, but it's a far cry from putting control over consistency in your hands.