MVCC: why readers and writers never wait for each other

A five-minute analytics report and a high-volume checkout flow are running at the same time on the same database. Without special design, one would freeze the other. With MVCC, neither waits — and the trick costs nothing at read time.

What MVCC does in one sentence

MVCC keeps every row’s history so each transaction sees a stable picture of the database without having to lock the rows other people are touching.

Why care. Without it, a five-minute analytics query would freeze every order coming in, and your dashboard would either lie about totals or block the checkout button.

The library metaphor

Imagine a busy library where every book has many copies stamped with the date they were taken off the shelf. When a reader asks for “the catalog as of when I started reading”, the librarian hands them a labeled copy frozen at that moment, even while a librarian behind the counter is binding a new edition. The reader reads their copy in peace. The librarian adds a new edition. Neither has to wait for the other; they are looking at different stamped copies of the same shelf.

Later, a janitor sweeps through and discards copies nobody is reading anymore. That sweep is what Postgres calls VACUUM, and the janitor only throws out a copy when no reader is still holding its date-stamp.

Sven and Otto — the concrete scenario

An app server runs a monthly report (Sven). The database receives thousands of orders per second (Otto). Without MVCC, the report either locks the orders table (freezing checkout) or sees half-finished updates. With MVCC, Sven gets a snapshot frozen at the report start; new orders go to fresh versions Sven cannot see. Report finishes, checkout never stalls.

The lost-update gap MVCC does not close

Two browser tabs edit the same profile. Tab A loads, you type. Tab B loads, edits one field, saves. You save Tab A: Tab B’s edit silently disappeared. That is lost update. MVCC alone does not fix it — it still gives both tabs a valid snapshot, but does not serialize their writes. Ask the database with SELECT FOR UPDATE or a stricter isolation level (covered in lesson 03).