What concurrent work can observe
Concurrent transactions can interleave reads and changes. Isolation specifies whether a query can see another transaction’s uncommitted work and whether later queries can observe newly committed changes.
Dirty reads, nonrepeatable reads, phantom reads, and serialization anomalies describe different phenomena. Preventing one does not automatically prevent the others. A stable view is also not, by itself, proof that all concurrent updates have a serially equivalent outcome.
References: [1]
The snapshot boundary matters
In PostgreSQL Read Committed, ordinary SELECT statements use snapshots taken when each statement begins. Two queries within one transaction can therefore differ. Repeatable Read instead uses a snapshot established by its first non-transaction-control statement.
Level names require implementation context. PostgreSQL maps Read Uncommitted to Read Committed and gives Repeatable Read stronger phantom protection than the standard minimum. Another product’s guarantees should be checked independently.
References: [1]
Conflicts still require coordination
Multiversion control can preserve older versions for readers while locks and conflict detection coordinate incompatible writes. SQLite WAL permits readers alongside a writer, but an outdated read snapshot cannot simply be promoted into a successful write.
Stronger guarantees can require waiting, monitoring, or retries. Applications must treat results from an abortable transaction as provisional until commit, rather than infer complete isolation merely from the presence of transaction syntax.