IsolationLevels

Postgres transaction isolation levels (read committed → serializable) and what anomalies each one prevents or allows.

Why we need this / what value this brings

The default isolation level determines which race conditions (dirty reads, lost updates) are actually possible in your app today.

When to use this

Whenever a bug looks like 'two requests overwrote each other's changes' or 'I read a booking slot as available but it wasn't'.

How to use or implement this

Know Postgres's default (read committed); use SELECT ... FOR UPDATE or a stricter isolation level for the specific transactions where a race would cause real damage (e.g. slot booking).

Research questions

• What's Postgres's default isolation level, and has a double-booking race condition ever been tested against it?

---

Empty folder — drop notes, links, and findings here as you research.