His example raises a question... 'items': [ {'product_code':'AX5718','qty':'1','price_per_unit':'5.00'}, {'product_code':'BB9388','qty':'3','price_per_unit':'2.00'}, ],

This is starting to look like an N queries type problem if I want to print out an receipt that includes the name of the product. I'll have to grab all of the product codes out of the order and iterate over the list to separately query for each of the n products to get its name. A join would be faster. And what happens when a product changes its code? Where's my surrogate primary key?

I also don't see where he gets the infrequently-written part of this: "If we restrict our use of SQL database to only what they are good at - small, infrequently-written, long-lived records with complex data relations - and start storing all our other data in more appropriate places, we won’t need to push our SQL databases to such high levels of performance or scale." A lot of frequently updated data is better off in a relational, or at least normalized, store. If the price of a stock is changing all of the time, do I want to keep updating it in everyone's portfolio document? If you denormalize, you turn a single update into a multiple document update, which turns into locking a bunch of documents or records which might be waiting for another multiple document update.

Now, if all of your writes are inserts, it's a little easier to live in a denormalized world.