What is an Isolation Level

An isolation level controls what changes from other concurrent transactions a transaction can observe. It is the I in ACID. Higher isolation levels provide stronger guarantees but reduce concurrency. Lower levels allow more parallelism but expose transactions to anomalies like dirty reads and phantom rows.

How it works

The SQL standard defines four isolation levels, from weakest to strongest:

  • Read Uncommitted -- a transaction can see changes from other transactions before they commit. This allows dirty reads -- reading data that may be rolled back. Almost no production system uses this level.
  • Read Committed -- a transaction only sees data committed before each statement executes. A query run twice in the same transaction can return different results if another transaction commits in between. This is the default in PostgreSQL and Oracle.
  • Repeatable Read -- a transaction sees a consistent snapshot taken at the start of the transaction. Re-reading the same rows always returns the same data. However, phantom reads can still occur: new rows inserted by other transactions may appear in range queries. This is the default in MySQL/InnoDB.
  • Serializable -- transactions execute as if they ran one at a time, in some serial order. No anomalies are possible. This is the strongest level but has the highest performance cost.

Most databases implement these levels using MVCC rather than locks. Each transaction reads from a snapshot, and the database detects conflicts at commit time. PostgreSQL's Serializable Snapshot Isolation (SSI) uses dependency tracking to detect dangerous patterns without blocking reads.

The trade-off is always the same: stronger isolation means more aborts (transactions that must be retried because they conflict) and lower throughput. Weaker isolation means higher throughput but more subtle bugs -- bugs that only appear under concurrent load and are notoriously hard to reproduce.

Why it matters

Choosing the wrong isolation level is a source of some of the most difficult bugs in production systems. Understanding what each level allows and prevents is essential for writing correct concurrent code against any relational database.

See How Transactions Work for the full walkthrough of isolation levels, anomalies, and MVCC.