Re: Transaction Isolation level for ERP software

> On Jul 15, 2026, at 10:34, Mihir Kandoi <kandoimihir(at)gmail(dot)com> wrote:
> • Is READ COMMITTED actually a better solution or should we go with retrying transactions?

There's nothing specific about ERP platforms regarding the transaction isolation mode, and READ COMMITTED isn't "better" than REPEATABLE READ or vice versa. It's a matter of what semantics you want for transactions: do you want a persistent snapshot that does not change (in from the perspective of the session with the open transaction) between statements, or can your application tolerate that?

In general, you want to use the weakest transaction isolation mode that gives you the semantics that you want. If your application is written to expect that the snapshot of the database does not change during the course of the transaction, you'll need REPEATABLE READ, and then need to come up with a solution for the serialization errors that you receive.

The source of serialization failures in REPEATABLE READ is two sessions attempting to update the same rows. That's probably the issue you should consider tracking down, since that has plenty of other potential problems (lock waits, deadlocks) apart from REPEATABLE READ.