ORMs tend to hide the underlying SQL operations, making it even harder to verify whether operations are concurrency safe.
A good starting point is to use CR instead of CRUD. Append-only tables with soft deletes aren't necessarily the most performant, but they're naturally less susceptible to race conditions. The lack of destructive modification (under normal operation) also makes it easier to diagnose problems and keep audit trails.
Can’t say I’ve worked that way in sql, but I have seen that pattern in append only data structures. With for instance a “order fulfilled” entry essentially is a delete operation on an outstanding order entry.
READ COMMITTED and REPEATABLE READ benefit from retry logic as well, not just SERIALIZABLE.
For a long time, I sought to write deadlock free code.
But that is very hard.
For example in PostgreSQL every UPDATE must be ordered, every DELETE must be ordered. [1]
Finally, I did myself a favor and create application-level retires.
This is 100% cool so long as (1) your deadlocks aren't so frequent so as to reach a performance problem and (2) the action is "replayable" (e.g. no read-once streams). Fortunately, these are both frequently true.
[1] https://dba.stackexchange.com/questions/257587/is-select-for...
Its also important to remember that in databases, you are more often optimising for IO usage than CPU.