I am not sure what this sort of an article achieves - its neither succinct enough to be a synopsis nor is it detailed enough to be an in-depth explanation.<p>It reminds me of one of those MS-Word Specification documents bandied about in enterprises. I never could grok one of those , this is no different.
I find that I need transactional databases less and less. Whether I specifically don't need SQL is not clear -- it's a great abstraction for storing and manipulating data.<p>Specifically, what I loose with transactions is fault tolerance and predictable performance while I find I don't really need atomicity in most places.<p>Fundamentally fault-tolerance is achieved by having few interdependencies among computer systems. Transactions makes that really hard to do for replicated databases and you need replication to be fault tolerant. So usually people cheat and settle for async replication, but then you really don't have transaction anymore since different parts of your system are seeing different states.<p>Transactions also lead to difficult to debug blocking behavior either due to deadlocks (btw, where else in computer systems is the advice that you have to destroy all abstraction and understand the entire locking order of your program in one place?) or locks getting held too long due to programming errors etc. I hate when my entire site hangs because a key table has locks on it due to some transaction getting accidentally left open.<p>Understanding database consistency levels and their nuances is extremely difficult and error prone as well. So you may not really be operating in the pristine transactional environment you thought you were.<p>Finally, programming to a non-transactional model is actually pretty easy in most cases. You just have to go into your project thinking about this upfront. And the decisions you make building a non-transactional site will probably increase how decoupled all the parts are which will make it scale better anyway.
Wow. That's a lot of information there.<p>Nitpick; the presentation is almost impossible to digest. A few tables instead of endless bullet lists would work wonders here.