seniorCore PostgreSQLPro answerGrounded in authoritative sources

Explain REPEATABLE READ vs SERIALIZABLE in PostgreSQL and when you would choose each.

This question sorts candidates quickly, because the definitions are easy to recite and the choice is hard to justify. Panels are not checking whether you can list four isolation levels. They want to hear what REPEATABLE READ actually guarantees in PostgreSQL specifically, an honest account of the anomaly it still permits, and then a choice driven by a business rule rather than a general preference for stronger guarantees. The follow-up is nearly always about cost: what SERIALIZABLE does when it detects a conflict, and what your application is now obliged to do about it. This page covers how to structure that answer in about ninety seconds, what is being scored while you talk, and the two places the answer usually falls apart.

What the interviewer is scoring

They listen for whether you tie the isolation level to a business invariant instead of reciting definitions, and whether you admit SERIALIZABLE still needs retries.

In short: A strong answer explains snapshot behavior, anomaly protection, retry cost, and the operational burden of high-contention workloads.

ProFrom a real interview loop

The spoken answer and the reasoning behind it

The question, the intro, what the interviewer is scoring, the reasoning outline, what you would verify and the follow-up probes are all open above. Pro unlocks the spoken answer to “Explain REPEATABLE READ vs SERIALIZABLE in PostgreSQL and when you would choose each.”, the reasoning behind it, and the verification that backs it.
  • The full 90-second answer, written first person, the way you would actually say it
  • How I reason through it: the mechanism, the decision points, and where the claim stops
  • Verification steps grounded in the documented behaviour and the source, with no lab claim attached.
  • Worked responses to the 3 follow-up probes listed above, plus the traps that lose the point

Card required. Cancel before day 7 and you are not charged.

Compare plans

How to reason through it

  • Say what Postgres RR actually guarantees (snapshot for the txn; no dirty/nonrepeatable/phantom reads).
  • Name what RR still allows: serialization anomalies / write-skew.
  • Explain SERIALIZABLE (SSI): same snapshot reads, plus aborts with serialization_failure, app must retry.
  • Pick a level from a business invariant, not from a generic 'stronger is better' rule.

What I would verify

  • Ask what already enforces the rule: a unique index, an exclusion constraint, or a single-row compare-and-set changes the answer.
  • Look for whether the invariant spans rows the writer never touches; that is the write-skew shape.
  • Check whether a retry path exists in the application before recommending SERIALIZABLE.
  • Watch measured abort rates under contention rather than assuming the level is free.

Follow-ups they push on

  • What SQLSTATE does the abort arrive as, and where do you handle it?
  • Does REPEATABLE READ allow phantom reads in PostgreSQL?
  • Give an invariant that a unique index cannot protect.

The probes are open. Pro carries the spoken answer, the reasoning behind it, and the verification steps, including a worked response to each of these.

Concepts tested

MVCCIsolation levelsSSI / write-skewRetry strategy

Learn it, run it, then say it

Three steps, in order. Nothing here is a detour.

Questions that go with this one