Skip to content

CONCEPT Cited by 2 sources

Read uncommitted isolation

READ UNCOMMITTED is the lowest ANSI-SQL isolation level. Transactions see the latest value of every row — including values written by other transactions that have not yet committed. A reader may observe a write that is later rolled back (or, in the degenerate case, a value that never existed in any committed state).

Why it is rarely chosen

Per Sugu Sougoumarane's canonical PlanetScale pedagogy post: "This isolation level is generally considered unsafe and is not recommended for distributed or non-distributed settings. This is because you may read data that might have later been rolled back (or never existed in the first place)." (Source: sources/2026-04-21-planetscale-pitfalls-of-isolation-levels-in-distributed-databases.)

The only anomaly READ COMMITTED prevents that READ UNCOMMITTED does not is the dirty read — but dirty reads are precisely the anomaly most applications cannot tolerate (reading a value that later disappears from the database is indistinguishable from a bug to the caller).

Legitimate use cases

Rare but real. Two shapes:

  1. Approximate-counts dashboards. Social-media like counters, real-time usage gauges, or other "roughly correct is fine" read workloads where the cost of locking or snapshot machinery outweighs the cost of a ±0.1% read error. (Source: sources/2026-04-21-planetscale-mysql-isolation-levels-and-how-they-work.)
  2. Bulk analytical reads against transactional tables where the analyst explicitly accepts that in-flight writes may be sampled. Most teams deploy a dedicated replica or read-only analytical store for this instead.

Mechanics

  • No locks on reads.
  • No MVCC snapshot — reads see the latest value in memory including uncommitted state.
  • Writes still take locks for their own consistency.
  • All three read anomalies (dirty, non-repeatable, phantom) are permitted.

Distinction from ReadPartialCommits

Sougoumarane's proposed ReadPartialCommits level is not READ UNCOMMITTED. ReadPartialCommits reads only committed rows — but does not wait for all participants of a distributed-transaction to commit before exposing locally- committed rows. The distinction is load-bearing: "Note that this is different from ReadUncommitted where you may read data that may eventually be rolled back." (Source: sources/2026-04-21-planetscale-pitfalls-of-isolation-levels-in-distributed-databases.)

Seen in

Last updated · 550 distilled / 1,221 read