Does running a transaction at the READ UNCOMMITTED isolation level change how its own INSERT, UPDATE and DELETE statements acquire locks, or let it overwrite a row another uncommitted transaction has already modified?

## The asymmetry to internalise Isolation levels are defined by which **read** anomalies they permit. Every named level — READ UNCOMMITTED included — leaves the write protocol alone. A useful way to hold it: - **Isolation level = what your transaction is allowed to see.** - **Atomicity and durability = what your transaction is allowed to do, and what survives.** Lowering the isolation level trades away read guarantees. It never trades away atomicity, never shortens how long your write locks are held, and never lets you interfere with another transaction's uncommitted writes. ## Why write locks must be held to commit A transaction that modifies a row takes that row's exclusive lock and keeps it until it ends. That duration is not a tuning choice; it is forced by rollback. Suppose the lock were released at the end of the statement: 1. T1 updates row R from 100 to 50 and releases the lock. 2. T2 updates R from 50 to 30 and commits. 3. T1 rolls back. What should R now be? Restoring T1's pre-image gives 100, destroying T2's committed change and violating T2's durability. Leaving 30 means T1's rollback did not undo its effect, violating T1's atomicity. There is no correct answer, so the situation must be prevented — by holding the write lock, which makes step 2 wait until step 3 resolves. This reasoning is independent of isolation level, which is exactly why the rule is universal. ## The dirty write, and why no level permits it The scenario above is the **dirty write**: overwriting a row version created by a still-uncommitted transaction. Every isolation level in the standard forbids it, and every engine enforces it. Note the elegant contrast with the dirty *read*. A dirty read is a hazard the application might, in principle, choose to accept — you see a value that might vanish, and if your use is approximate you may not care. A dirty write is not accept-able by anyone, because it corrupts the engine's own ability to implement rollback. One is an application-level risk that can be delegated; the other is an engine-level invariant that cannot. ## What still happens at READ UNCOMMITTED - **Blocking on write-write conflicts.** Two transactions updating the same row serialise, exactly as at any other level. This is the most common source of contention in an OLTP system, and this level does nothing about it. - **Deadlocks.** Two transactions taking row locks in opposite orders still deadlock and one is still aborted as the victim. Lowering isolation does not reduce deadlock frequency for write-write cycles. - **Constraint enforcement.** Unique indexes, foreign keys, and check constraints are enforced at write or commit time regardless of level. Note the interaction: a unique-index check may have to wait on a conflicting uncommitted insert to learn whether the duplicate becomes real. - **Lock escalation and range locking on writes**, where an engine implements them, follow their normal rules. ## What actually changes Only the read path, and only in engines that implement the level literally. In a lock-based engine, your `SELECT` statements — and the read phase of your own statements, in engines where that phase takes shared locks — stop taking shared locks. The observable effects are: - your reads never wait behind another transaction's exclusive lock; - your reads may return provisional versions that later disappear; - your reads no longer block writers, which historically was the *other* half of the appeal: a long scan at a stronger level could stall writers for its whole duration. In multi-version engines, where reads are already served from committed versions without locking, this changes little or nothing, which is why several such engines map the level onto READ COMMITTED. ## The operational conclusion If your incident is **writers blocking writers** — long lock waits on hot rows, rising deadlock counts, queues behind a slow transaction — the isolation level is the wrong lever entirely. The effective levers are: shorten transactions so locks are held briefly; never hold a write lock across a network call or user think time; touch rows in a consistent order to break deadlock cycles; reduce the number of rows a statement locks by improving its access path; and split hot single rows into shardable counters where the design allows. If your incident is **readers waiting on writers** on a lock-based engine, the isolation level is a lever, but a crude one — and the better answer is usually a multi-version read path or a read replica rather than accepting rolled-back data into a report.