The problem is that in my experience a lot of devs thing SQL transactions with the read committed transaction level given them guarantees they do not. Then the

The problem is that in my experience a lot of devs thing SQL transactions with the read committed transaction level given them guarantees they do not. Then the DB gets into a bad state. And then they switch to nosql because SQL "doesn't work anyway". :facepalm: (I have seen that story more then once.) Most applications can get away with read committed + a sprinkle of row level locks (mainly `for update`). If not I prefer (in postgres) to use full serializable snapshot isolation with scaffolds which automatically setup/comitts/aborts and retries transactions, setting read only and deferrable as needed etc. Sadly it's often not viable.