You're assuming that transactions require locks. That's not necessarily the case with MVCC and SERIALIZABLE semantics, but you may have to retry the transactio

You're assuming that transactions require locks. That's not necessarily the case with MVCC and SERIALIZABLE semantics, but you may have to retry the transaction (from scratch) if it fails. This looks a lot like what you'd get if you were using locks. Somewhere, though, there will be locks, indeed. Pushing the locking to the edges of the system helps keep the core composable. There's no panacea, of course. Also, an RDBMS can order locks because once you've decided what INSERTs/UPDATEs/DELETEs you're doing, they can be sorted and run in a different order than they were requested (after all, if the transaction is atomic, then the internal order doesn't matter). You can absolutely build all of that (transactions, lock ordering, ...) in any OOP (or FP or other) language of your choice. But that's essentially recreating part of an RDBS -- if you're after reuse, just use an RDBMS so you don't have to recreate its functionality. Using an RDBMS w/o an ORM helps you avoid all the issues raised by TFA. Further, using an EAV design gives you many benfits as outlined in TFA and elsewhere in the commentary here and on the web.