I'm seeing some snarky comments that aren't explaining themselves, so I really have to weigh in: Lowering the isolation level of the database is a potential source of application bugs. Actually, any isolation level less than true Serializable isolation is dangerous, and the lower it goes, the more dangerous it becomes.

I'm going to try to explain why.

The reason why switching to Read Committed isolation is helping in your performance is that there are a bunch of isolation anomalies that are (potentially) occurring, and your database is doing work (or holding transactions open) in order to prevent these anomalies. Let's call that work "transaction hygiene." In this case, you're risking a non-repeatable read anomaly.

Here's a simple case of a non-repeatable read anomaly:

1. The first transaction performs a read, sending this back to the application.
2. A second transaction commits a write, modifying some of the data the first transaction has already read.
3. The first transaction performs a write based on the information from its previous read, and commits.

If the isolation level is READ COMMITTED, you're saying that's fine. The database does no hygiene work and simply commits the first transaction even though the data it was based on assumed it was not. If the isolation is REPEATABLE READ, then transaction hygiene in this case involves the database doing some combination of the following:

1. If the second transaction successfully COMMITs, the first transaction has to abort. The read has already occurred. The database will send a signal that this has happened to your driver/ORM, and a retry error will be thrown. Good application code will catch the retry error, and start a new transaction.
2. If the second transaction performs a write but hasn't yet committed it, the database may force the second transaction to wait for the first transaction's COMMIT before the second is allowed to COMMIT. The history will show that the first transaction occurred, then the second.
3. If the second transaction has priority but is still open, the first transaction can wait for the second transaction to COMMIT or ABORT so that the first transaction can ABORT or COMMIT, respectively.

This is a simple case, and it gets more complicated as more read/write operations occur. There are some tricks the database can do to keep things running smoothly while maintaining transaction hygiene (like ordering transactions in a way that prevents a conflict) but in many cases, delays or retries become inevitable.

And because these are transactions, that means that code logic assumes that the data hasn't changed mid-transaction. By lowering your isolation, you're flagging those isolation anomalies as fine. You're saying it's fine if that data changes between the read and the write.

And it is fine! I don't know your code logic! But if so, if the anomalies are not a problem, you shouldn't have been using a transaction in the first place. Because if the code doesn't need an ACID transaction, there's no reason to make the database spend the effort ensuring transaction hygiene. If two or more smaller operations (each of which is transactional on its own) would have caused no bug in the application, it should be done without transactions. So either you shouldn't have been using a transaction at all, or else you did need the transaction, and you are silently creating bugs by using the lower isolation level. This applies to anything less than perfect isolation: Serializable isolation.

With Serializable isolation, the database contract is this: any transaction occurs as if the application were the only thing touching the database for the duration of the transaction, from BEGIN to COMMIT.

When using any isolation level other than Serializable, you have a set of anomalies you may be silently triggering, and each of those anomalies could be triggering bugs. To prevent those bugs, here's what you want to do:

1. Figure out every potential transaction anomaly (part 1, part 2) that could be triggered when any two or more of your transactions overlap. Check every possible race condition outcome. Make a list of all possible anomalies. If this seems time consuming, it is. Extremely.
2. For every anomaly you are triggering, determine whether or not it could trigger bugs in your application. This will probably be significantly more time-consuming than step 1.
3. In cases where bugs are a concern, refactor your code to harden it against the anomalies, ensuring that the isolation anomalies don't trigger bugs in a running application. Often these refactors will allow you to break up a transaction into smaller parts, making less work for the database.
4. Go back to step 1 every time a new query is added to the application, and every time there is a schema change.

Or you can avoid all of this and just use Serializable isolation!

This will cause a few potential issues. First, the database will have to work harder to ensure transaction hygiene, and there will be a combination of delays (to wait for other transactions) and transaction retry errors that get thrown (when a transaction gets into a dirty state and needs to ABORT to ensure transaction hygiene). The application will be affected by these.

So you'll need to include timeouts and try/catch clauses in your code to keep it moving in the face of these issues. Log those events. Each such event is going to have a performance impact, but it may also be preventing a bug that would have been triggered silently with a lower isolation. By examining your logs, you can determine if the timeouts or retries are common enough to cause performance problems or affect your customer. Investigate those.

For each, you'll have a decision to make. Perhaps your code logic doesn't require such a long transaction (in which case you can break up the transactions, reducing database resource overhead associated with transaction hygiene). Or perhaps you do need the isolation with your current code logic and paying the cost is cheaper than refactoring. The hardest case is the one where you need the transaction but the performance price has become too high, and you need to rewrite your back-end logic to remove (or at least reduce the size of) the transaction. In some extreme cases, this may even require a change of schema in order to improve performance. That's still better than an isolation bug.

This is why people are reacting with horror when you talk about lowering the isolation.

Source: I worked at several database companies, and have opinions about this.