What is the Read Committed Isolation Level?
Learn how the Read Committed isolation level prevents dirty reads, why non-repeatable reads still occur, and its common defaults.
Expected Interview Answer
Read Committed is an isolation level that guarantees a transaction only ever sees data that has been committed by other transactions, eliminating dirty reads while still allowing non-repeatable reads and phantom reads between separate statements in the same transaction.
Under Read Committed, each individual query sees a fresh snapshot (or acquires fresh locks) of committed data at the moment it runs, so it never returns another transaction’s uncommitted write. However, because that snapshot is taken per-statement rather than per-transaction, running the same query twice within one transaction can return different results if another transaction commits changes in between. This is the default isolation level in most databases, including PostgreSQL and Oracle, because it balances reasonable consistency with good concurrency.
- Eliminates dirty reads entirely
- Good balance of consistency and concurrency
- Default level in many production databases
- Lower locking overhead than stricter levels
AI Mentor Explanation
Think of a scoreboard that only updates once the third umpire has fully confirmed a decision — no more provisional numbers shown mid-review. But if you glance at the total, look away, and glance again a minute later, it may have changed because another confirmed boundary was added in between. Read Committed guarantees you only ever see confirmed scores, but does not promise the number stays the same across two separate looks.
Step-by-Step Explanation
Step 1
Set the isolation level
Configure with SET TRANSACTION ISOLATION LEVEL READ COMMITTED, often the database default.
Step 2
Begin the transaction
Start the transaction that will issue one or more read queries.
Step 3
Take a per-statement snapshot
Each SELECT sees the latest committed data as of when that specific statement runs.
Step 4
Accept re-read variability
Re-running the same query later in the transaction can return different committed results if others have committed in between.
What Interviewer Expects
- Clear explanation of why dirty reads are prevented at this level
- Understanding that visibility is evaluated per-statement, not per-transaction
- Awareness that non-repeatable reads and phantom reads are still possible
- Knowledge that this is the default level in databases like PostgreSQL and Oracle
Common Mistakes
- Believing Read Committed prevents non-repeatable reads
- Confusing per-statement snapshots with a single per-transaction snapshot
- Assuming Read Committed is equivalent to Repeatable Read
- Not knowing which databases default to this level
Best Answer (HR Friendly)
“Read Committed makes sure you never see another transaction’s unfinished, uncommitted changes — every value you read has actually been confirmed. The catch is that if you read the same row twice in one transaction, it might have changed in between, because each read only guarantees a fresh, committed snapshot at that moment, not a consistent one across the whole transaction.”
Code Example
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
BEGIN TRANSACTION;
SELECT balance FROM Accounts WHERE account_id = 1; -- returns 500
-- Meanwhile, another transaction commits a deposit of 100
-- to account_id = 1 in this window
SELECT balance FROM Accounts WHERE account_id = 1; -- returns 600
-- Both reads only ever saw committed data (no dirty read),
-- but the two reads within the same transaction differ
-- because each statement re-checks the committed state.
COMMIT;Follow-up Questions
- How does Read Committed differ from Repeatable Read?
- What is a non-repeatable read and why does Read Committed allow it?
- Which databases default to Read Committed and which default to something stricter?
- How does Read Committed implement its guarantee — locking or MVCC snapshots?
MCQ Practice
1. What does Read Committed guarantee that Read Uncommitted does not?
Read Committed ensures every read only sees committed data, eliminating dirty reads, unlike Read Uncommitted.
2. Under Read Committed, running the same SELECT twice in one transaction can return different results because of what?
Read Committed takes a fresh look at committed data per statement, so intervening commits from other transactions can change the result — a non-repeatable read.
3. Which isolation level is the default in PostgreSQL?
PostgreSQL, like many production databases, defaults new transactions to Read Committed for its balance of consistency and concurrency.
Flash Cards
What is Read Committed? — An isolation level where every read only sees committed data, preventing dirty reads.
What anomaly can still occur under Read Committed? — Non-repeatable reads and phantom reads, since visibility is checked per statement.
Is Read Committed a common default? — Yes, it is the default isolation level in databases like PostgreSQL and Oracle.
Read Committed vs Read Uncommitted? — Read Committed blocks dirty reads by only exposing committed data; Read Uncommitted does not.