Comparison
Repeatable readvsSerialisable
Repeatable read
you read the same row twice inside one transaction and are guaranteed to get the same answer both times.
An isolation level where the whole transaction sees one consistent snapshot, so re-reading a row is stable. It removes non-repeatable reads; depending on the engine it may or may not remove phantoms, and it does not remove write skew. In PostgreSQL it is snapshot isolation and can abort your transaction with a serialisation failure you must be prepared to retry.
Full entry →Serialisable
the database promises the result is as if the concurrent transactions had run one after another, and aborts one of them to keep that promise.
The strongest isolation level: the outcome is equivalent to some serial order of the transactions. It eliminates every anomaly, including write skew, which is why it is the correct answer for financial invariants. The cost is aborts under contention, so every transaction needs a retry loop, and throughput drops on hot rows.
Full entry →