Great article. I mentioned I had one comment and one question, so here they are 😊

I have observed that many critical databases on RDBMS don't support Serializable, such as Oracle, which leaves me with mixed feelings. On one hand, Serializable is the ideal isolation level. On the other hand, staying in Read Committed and managing the few complex transactions using SELECT FOR UPDATE or updating a common parent key is not a huge effort. Read Committed has the significant advantage of not requiring handling retryable errors, as the database can retry at a newer read time. But as you say may be error-prone if the developer doesn't handle complex transactions carefully. And the test coverage for race conditions is often low.

And the question is about "In many DBMSs (especially PostgreSQL), serializable transactions are serialized only with other serializable transactions"

Do you have an example to demonstrate this behavior in PostgreSQL? I recall seeing it documented but never tested, and I can't find that documentation anymore. In YugabyteDB, we perform additional work if there are concurrent Serializable transactions, but they are usually rare, so we are considering optimizing for that scenario.