It's odd that he put NoSQL at lower level of abstraction than SQL. In a way, it makes sense, because yes you do have to reimplement many SQL things.<p>But I always thought that the attraction to NoSQL was that you didn't have to unravel your application's objects into tables. You just stuck them in there. You worried about reports later.
An interesting article. I'm glad to see someone giving an equal treatment of SQL and NoSQL databases for a change. I appreciate the analogy of SQL being an optimized and general-purpose high-level language and NoSQL being a more powerful but specialized low-level or assembly language.<p>However, I feel like the article fundamentally fails to address the core question of "When should I pick NoSQL over SQL?" If SQL is indeed the choice 99 times out of 100, how can you know when you are faced with that 1-in-100 time when NoSQL is actually the right option?