CONCEPT

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: .)

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:

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: .)
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: .)

Seen in¶

— canonical wiki framing of ReadUncommitted as "generally considered unsafe" for both distributed and single-node settings, with the rolled-back-value and never-committed-value failure modes explicitly named. Contrasted with the ReadPartialCommits proposal.
— Brian Morrison II's MySQL-implementation framing: performance-over-consistency default for workloads tolerating ~1% read-value errors (social-media like counts is the archetype).