Isolation Level

In Turkish: Yalıtım Düzeyi

Updated September 30, 20262 min read

In short

An isolation level is a database setting that controls how much concurrent transactions can see of each other's changes, trading strictness for speed.

What is a transaction isolation level?

Isolation is the I in ACID, and an isolation level decides how strictly the database keeps concurrent transactions from affecting each other. The SQL standard defines four levels, from weakest to strongest: Read Uncommitted, Read Committed, Repeatable Read, and Serializable. You can usually set a default for the database and override it for a single transaction.

Each level is defined by the anomalies it prevents. A dirty read means seeing another transaction's changes before they are committed; a non-repeatable read means reading the same row twice and getting different values because someone else committed in between; a phantom read means rerunning a range query and finding new rows. Read Committed prevents dirty reads, Repeatable Read also prevents non-repeatable reads, and Serializable makes the outcome the same as if transactions had run one at a time. Databases implement this with locks or with multiversion concurrency control (MVCC), which gives each transaction a consistent snapshot of the data, and the exact guarantees vary between databases, so check your database's documentation.

An analogy is a shared document that several people are editing. At the lowest level you can see other people's half-typed sentences; at the highest level it is as if everyone took turns, each editing alone. Stricter levels bring fewer surprises but more waiting, blocking, or transactions that fail with a serialization error and must be retried.

Isolation levels are often confused with consistency models such as eventual consistency. Isolation levels describe how transactions interact inside one database, while consistency models describe how copies on different servers agree. They are also not the same as explicit locking: an isolation level sets the default guarantees, while tools like SELECT ... FOR UPDATE or optimistic locking protect specific operations, such as preventing lost updates, at lower levels.

Key takeaways

The standard levels are Read Uncommitted, Read Committed, Repeatable Read, and Serializable.
Higher levels prevent more anomalies: dirty reads, non-repeatable reads, and phantom reads.
Serializable behaves as if transactions ran one after another.
Stricter levels cost more waiting and more retries after conflicts.
Defaults differ between databases, so check which one you are using.

Example

Running one transaction at the strictest level (PostgreSQL syntax)sql

BEGIN ISOLATION LEVEL SERIALIZABLE;

SELECT balance FROM accounts WHERE id = 1;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;

COMMIT;
-- If a concurrent transaction conflicts, a statement or the COMMIT
-- fails with a serialization error, and the application should retry.

-- Check the current default level
SHOW default_transaction_isolation;

Readers ask

What is the default isolation level?

It depends on the database. PostgreSQL, Oracle, and SQL Server default to Read Committed, while MySQL with the InnoDB engine defaults to Repeatable Read.

What is a dirty read?

A dirty read happens when a transaction reads data that another transaction has changed but not yet committed. If that other transaction rolls back, the first one has used data that never officially existed.

Why not always use Serializable?

Serializable gives the strongest guarantees but can reduce throughput, because transactions wait for each other or get aborted and must be retried. Many applications use Read Committed and add targeted locking where a race condition matters.