Multi-Version Concurrency Control (MVCC) is a strategy for letting many transactions read and write a database at the same time without forcing them to wait on each other. Instead of locking a row while one transaction reads it, the database keeps multiple versions of that row. Each transaction is given a consistent snapshot of the data as it existed at a particular moment, so it never sees half-finished changes from other transactions in flight.
The payoff is that reads and writes stop interfering. The PostgreSQL documentation puts it plainly: “in MVCC locks acquired for querying (reading) data do not conflict with locks acquired for writing data, and so reading never blocks writing and writing never blocks reading.” Each SQL statement sees a snapshot of the data as it was some time ago, which preserves transaction isolation while avoiding the lock contention that a pure locking scheme would create.
Under MVCC, an update does not overwrite a row in place; it creates a new version and leaves the old one for transactions that still need to see it. This is also visible in SQLite’s WAL mode, which the documentation describes as letting “readers continue operating from the original unaltered database while changes are simultaneously being committed” - readers and the writer proceed concurrently against different versions of the data.
MVCC is the foundation of high-concurrency database engines. PostgreSQL and Oracle both rely on it to serve many simultaneous users with good throughput. The trade-off is that old row versions accumulate and must eventually be cleaned up; in PostgreSQL this housekeeping is handled by the VACUUM process, which reclaims the space held by versions no transaction can still see.