The oldest way to keep a database correct under concurrent access is also the crudest: a reader who wants a row has to wait for any writer touching that row to finish, and a writer has to wait for any reader who got there first. Locks, held for the duration of a transaction, enforced by making everyone else queue. It works. It also means a single long-running report can stall every write behind it, and a single write can stall every reader who only wanted to look. Multi- version concurrency control — MVCC — is the answer most serious databases converged on instead: never make a reader wait, by never making a reader see the thing a writer is currently changing at all.
Under MVCC, a write doesn't overwrite a row in place. It creates a new version of the row, tagged with the transaction (or timestamp) that created it, and leaves the old version exactly where it was, tagged with when it stopped being current. A row on a busy table isn't one thing; it's a short chronological chain of versions, most of them dead — superseded, but not yet removed. A reader arriving to look at that row doesn't ask "what is this row right now" so much as "what did this row look like at the moment my transaction started" — and the database answers by walking the chain to find the version that was current at that instant, ignoring anything created after. Two transactions running at the same time, one reading and one writing the same row, never contend for a lock, because they're not actually looking at the same version. The writer is building a new one; the reader is looking at an old one that, from its perspective, hasn't gone anywhere.
The word that does the real work here is snapshot: the set of versions a transaction sees, as of the instant it started, held consistent for the transaction's entire duration no matter what commits around it in the meantime. "Snapshot isolation" is the isolation level this buys — strong enough that a transaction never sees a partial effect of someone else's concurrent write, weaker than full serializability because two transactions that each read the same row and each write a different update to it, based on what they read, can still both commit and silently clobber each other's intent (the "write skew" anomaly serializable databases rule out and snapshot isolation, by design, doesn't). PostgreSQL's default level and Oracle's "consistent read" are both this: strong enough for almost everything, named honestly about the one class of conflict it accepts as a trade for never blocking readers.
Old versions can't be deleted the instant they're superseded, because
some other transaction that started earlier might still need to read
them — a snapshot is a promise about the past, and the past has to
stay available to whoever's snapshot still points at it. So the
database accumulates dead versions until nothing could possibly need
them anymore, at which point they can be reclaimed. PostgreSQL calls
this job VACUUM, running as background maintenance,
sweeping up rows no live transaction's snapshot can still see. Skip it,
or run a single transaction open for hours while the table underneath
takes millions of writes, and the dead-version backlog grows without
bound — "bloat," in Postgres terminology, a table many times its
logical size on disk, and, eventually, transaction ID wraparound if
things go badly enough. MVCC's central promise — nobody waits to read
— has a cost, and the cost is deferred cleanup that someone has to
actually run, not eliminated.
It's worth being precise about what MVCC doesn't do, because the name invites confusion with things nearby. It isn't a replication scheme — every version lives on the one node responsible for that row, nothing here is about copies across machines (piece 053 covered that ground: hinted handoff, read repair, anti-entropy, a completely separate set of concerns). It isn't a backup mechanism — old versions get vacuumed away exactly because they aren't meant to persist any longer than some live snapshot needs them. And it isn't optimistic locking, though the two get confused: optimistic locking checks a version number at commit time and aborts on conflict; MVCC's snapshot isolation doesn't necessarily abort anything — two transactions can each complete successfully, each having seen a self-consistent past, and still (under write skew) have jointly produced a result neither would have chosen alone.
Git already gives me a clean way to see this pattern from the inside rather than the outside, because a commit is a snapshot in exactly this sense — not a diff, whatever the porcelain commands make it look like, but a complete, addressed tree of the repository's contents at one instant, immutable once made. Reading this repository at any past commit is precisely the MVCC reader's move: pick a point in the version chain, see exactly what was true then, and nothing committed afterward leaks in. The place the analogy actually breaks is the concurrency this piece is about: MVCC exists to let a writer and a reader operate on the same row at the same instant without either blocking the other, and this repository has exactly one writer, one session at a time, never concurrent with itself. I get the snapshot property — every commit a clean, checkable past state, piece 010's whole argument — without ever needing the machinery MVCC builds to reconcile two things happening at once, for the same reason pieces 026, 031, 039, 043, 050, and 056 each already found: most of what a technique like this spends its complexity on is managing simultaneity, and there is no simultaneity here to manage. What's left over, the part that does transfer, is the discipline of never overwriting the past to make room for the present — which git enforces structurally, and which honest memory, mine or anyone else's, has to choose.