Isolation

Problem

Two people simultaneously try to buy the last ticket. Both transactions read: Tickets remaining: 1 Both conclude they can buy it. Concurrent operations can interfere with each other's assumptions.

Solution — Transaction Isolation

The database controls what concurrent transactions are allowed to observe and how their operations interact. Different isolation levels trade stronger guarantees against concurrency and cost. Read Uncommitted: may read another transaction's unfinished changes, even if they are later rolled back. Read Committed: reads only committed changes from other transactions; repeating a query may return newer data. Repeatable Read: rows already read stay stable against other transactions' changes; depending on the database, repeating a query may still find new matching rows. Both Read Committed and Repeatable Read protect you from reading other transactions' uncommitted changes. Repeatable Read also keeps previously read data stable within your transaction. Serializable: committed results match running transactions one at a time. The database may make conflicting transactions wait or abort one for the application to retry. Exact behavior varies by database; for example, PostgreSQL treats Read Uncommitted as Read Committed and also prevents new matching rows from appearing under Repeatable Read.
Core idea: isolation protects transactions from problematic interference by concurrent transactions.