You set your transaction isolation to REPEATABLE READ thinking you're safe. You run the same query twice in one transaction and get different row counts. What happened? A phantom read: another transaction inserted (or deleted) rows that match your WHERE clause between your two reads. Repeatable Read protects rows you've already seen from being modified — it doesn't stop new rows from appearing.

The SQL standard defines four isolation levels by which anomalies they prevent:

• Read Uncommitted: allows dirty reads, non-repeatable reads, phantoms
• Read Committed: blocks dirty reads only (PostgreSQL default)
• Repeatable Read: also blocks non-repeatable reads, but phantoms still allowed by the standard
• Serializable: blocks all three

Non-repeatable read vs phantom read: non-repeatable is the same row changing between reads (UPDATE). Phantom is the set of matching rows changing (INSERT/DELETE).

Real-world example. A bank runs end-of-day interest calculation:

• T1 begins: SELECT SUM(balance) FROM accounts WHERE branch = 'NYC' → $10M
• T2 inserts a new $1M account in NYC and commits
• T1 runs SELECT COUNT(*) FROM accounts WHERE branch = 'NYC' → count includes the new row
• T1's interest calculation is now based on a sum and count that don't match

Under standard Repeatable Read, this is legal. The fix depends on your database:

• PostgreSQL: Repeatable Read uses snapshot isolation and does prevent phantoms for reads — but write skew can still corrupt invariants. Use Serializable for true safety.
• MySQL InnoDB: Repeatable Read uses next-key locks to prevent phantoms on locking reads (SELECT ... FOR UPDATE).
• SQL Server: Repeatable Read does not prevent phantoms. You need Serializable or explicit range locks.

Rule of thumb. If your transaction makes a decision based on the absence of rows ("no account exists with this email, so insert one") or aggregates over a set ("sum all matching rows"), Repeatable Read is not enough. Use Serializable, or enforce the invariant with a unique constraint, advisory lock, or SELECT ... FOR UPDATE on a sentinel row.

Cost trade-off. Serializable on Postgres uses SSI (Serializable Snapshot Isolation), which adds ~10-30% overhead and can abort transactions with serialization failures. Your code must retry. Read Committed is cheap but lets anomalies through. Pick per-transaction, not per-database.