I think the main part of this that resonates with me is not wanting a disconnect between the parts of your development that happen "above" and "below" the datab

I think the main part of this that resonates with me is not wanting a disconnect between the parts of your development that happen "above" and "below" the database abstraction. For this reason many people seem to be using databases more as lightweight, reliable storage and pushing as much logic as possible up into the application. I hear many stories of people using SQL databases with one big table with a key column and a value column. The article also begs the question: Why not just use a filesystem for state storage? Two big issues: 1) It's not very good at creating/updating lots and lots of tiny files and, 2) aside from some clunky locking, it doesn't have any good concurrency control mechanism for concurrent access to data. This is where databases become valuable. I build FoundationDB, a database that aims to decouple the storage substrate (which we are building as an ordered, ACID key-value store) from the data models and interfaces (which we are building with our community as open-source projects). Not to say that this solves all problems, but it does align, I think, with the author's way of thinking.