How MVCC enables non-blocking reads

WHAT THIS TESTS The interviewer wants to know if you understand the core mechanism behind readers-don't-block-writers, common in PostgreSQL and others.

A GOOD ANSWER COVERS MVCC keeps multiple versions of each row instead of overwriting in place. When a transaction updates a row, the engine writes a new version tagged with the transaction's identifier, while the old version remains for transactions that should still see it. Each transaction reads against a snapshot: a consistent view of which versions were committed and visible as of its start point. Because a reader simply consults the appropriate version rather than acquiring a lock on the row, it never waits for a concurrent writer, and a writer never waits for readers. This is why reads are non-blocking. Two costs follow: write-write conflicts still require coordination, since two transactions updating the same row must serialize, and obsolete versions accumulate, requiring a cleanup process such as PostgreSQL's vacuum to reclaim space.

COMMON WRONG ANSWERS Claiming MVCC eliminates locking entirely; writers still need conflict handling and certain operations take locks. Forgetting that dead versions must be garbage collected, which causes bloat if neglected. Confusing snapshot isolation's guarantees with full serializability, since plain snapshot isolation still allows write skew.

LIKELY FOLLOW-UPS How is row visibility determined from transaction IDs? What is vacuum and why does bloat matter? How does snapshot isolation differ from Serializable? How do writers detect conflicts?

ONE CONCRETE EXAMPLE A long analytics query starts and sees account balances as of its start time. Meanwhile users keep updating balances, creating new row versions. The report finishes reading the consistent old snapshot without ever blocking those writers and without being blocked by them.