asdsdf

jgfkjhg

never main

May 20, 20262 min read7 views

Read Committed

READ COMMITTED
means a transaction can only read data that has already been committed.
It is the default isolation level in PostgreSQL.

Simple Meaning

You cannot see uncommitted changes from another transaction.
But you can see new committed changes if another transaction commits before your next query.

Example

Transaction A:
sql
BEGIN;

UPDATE accounts
SET balance = 500
WHERE id = 1;

-- not committed yet
Transaction B:
sql
SELECT balance
FROM accounts
WHERE id = 1;
Transaction B will not see 
500
yet.
Because Transaction A has not committed.

After Commit

Transaction A:
sql
COMMIT;
Transaction B runs again:
sql
SELECT balance
FROM accounts
WHERE id = 1;
Now Transaction B can see the updated value.

Important Behavior

In 
READ COMMITTED
, each query sees the latest committed data when that query starts.
So inside one transaction:
sql
BEGIN;

SELECT balance
FROM accounts
WHERE id = 1;

-- another transaction commits update here

SELECT balance
FROM accounts
WHERE id = 1;

COMMIT;
The two 
SELECT
queries can return different values.

What It Prevents

ProblemPrevented?
Dirty readYes
Non-repeatable readNo
Phantom readNo

Dirty Read Prevention

Dirty read is prevented because uncommitted data is hidden.
text
READ COMMITTED = only read saved data

Non-Repeatable Read Can Happen

Same row can show different values inside the same transaction if another transaction commits an update between your reads.

Phantom Read Can Happen

Same query can return different rows inside the same transaction if another transaction inserts or deletes matching rows and commits.

Easy Memory Trick

READ COMMITTED
means:
text
I only read committed data.
But each query gets a fresh committed view.

When To Use

Use 
READ COMMITTED
for most normal app queries.
Good for:
  • reading user data
  • normal CRUD operations
  • simple updates
  • most API requests

When Not Enough

Use stronger isolation when you need the same transaction to see stable data.
Example:
  • financial calculations
  • complex reports
  • stock/booking logic
  • multiple reads that must stay consistent
Then consider:
sql
REPEATABLE READ
or
sql
SERIALIZABLE

Found this useful? Have thoughts or questions?

Reach out →
All posts