Versioning permeates the whole system

MVCC is not just another concurrency control protocol bolted on top. "The concept of versioning permeates all throughout the database system" — every layer must be aware it is dealing with multiple versions 27:46 28:24.

The four decisions

  1. Concurrency control protocol — 2PL, OCC, or timestamp ordering 29:35
  2. Version storage — append-only, time-travel, or delta 28:24
  3. Garbage collection 44:09
  4. Index management 52:14

These decisions are not independent. How you store versions strongly determines what happens with index management, especially secondary indexes 28:24 35:51.

The lecture's headline verdict

"The worst implementation of MVCC that is out there today... is actually PostgreSQL." MySQL and Oracle do it better, and every other modern system — unless it is a PostgreSQL fork — does it the MySQL/Oracle way 28:59 29:35.

Decision 1 — concurrency control protocol

You still need all the machinery from earlier lectures 29:35:

  • Two-phase locking — lock table, deadlock detection or prevention, all of it 29:35.
  • OCC — whether you keep a private workspace for new versions plus a validation step is implementation-dependent 30:02.
  • Timestamp ordering — assign a timestamp, commit in that order. This gives you snapshot isolation by default; serializability requires extra work (covered in the advanced course, not this one) 30:02 30:26.