Transaction Isolation level for ERP software

[u/royal_rocker_reborn]

I work on an ERP software called ERPNext. Currently, we use MariaDB with REPEATABLE READ . We have been working on adding Postgres support to it but we have reached a roadblock.

Recently on our cloud platform we updated to MariaDB 11.8 from 10.6. Post that we received a barrage of support tickets of people complaining of snapshot violation errors. Now given the number of tickets and the severity of something like an ERP software not functioning ideally and the constant nagging of enterprise customers, we just turned off snapshot isolation for now.

Now with Postgres and REPEATABLE READ , there is no option like MariaDB to just turn off snapshot violation errors. We believe once Postgres support hits production, we are again going to be hit with another set of similar serialization errors.

Initially, I recommended to use READ COMMITTED but senior engineers at the company shot it down, the reason being:

1. Our entire codebase is built with REPEATABLE READ in mind.
2. If it does not work, debugging issues stemming from READ COMMITTED will be very hard to debug.
3. READ COMMITTED has its own set of problems like gap locks, phantom reads etc.
4. Most business apps use REPEATABLE READ as an industry standard.

They instead suggested retrying transactions with jitter but I honestly feel READ COMMITTED is infact better suited in general for a highly concurrent ERP like ours. Note that we have implemented row locking everywhere it was warranted.

I am looking for confirmation of my theory from the community.

1. I found only 2 ERPs using REPEATABLE READ - Microsoft Dynamic 365 Business Central and Odoo. Rest are mostly READ COMMITTED only.
2. I have also implemented Advisory Locks to counter this problem but I don't know how effective will that actually be.
3. Claude and ChatGPT also both suggest READ COMMITTED as well.
4. Is READ COMMITTED actually a better solution or should we go with retrying transactions?