TIL: How MVCC Lets Reads and Writes Run Concurrently

High-concurrency systems have a fundamental problem: reads and writes shouldn't constantly block each other.

That's where MVCC (Multi-Version Concurrency Control) comes in.

Once you understand MVCC, many database concurrency concepts become much easier to understand—including how GBase Database handles concurrent transactions.

The Core Idea

Instead of making every transaction read the latest version of data directly, MVCC maintains multiple versions of rows.

A transaction can read the version that's visible to its snapshot while another transaction is modifying a newer version.

In simplified terms:

• Reads don't necessarily block writes — a SELECT can read a visible version while another transaction updates the row.
• Writes don't necessarily block reads — readers can continue using an older visible version while a write is in progress.
• Write vs. write still needs coordination — locks or other concurrency mechanisms prevent conflicting updates.

That's the key distinction:

MVCC primarily reduces read-write contention. Locks primarily coordinate conflicting writes.

A Simple Example

Consider an account with a balance of $1,000.

Transaction A starts an update:

BEGIN;

UPDATE accounts
SET balance = balance - 100
WHERE id = 1;

At roughly the same time, Transaction B runs:

SELECT balance
FROM accounts
WHERE id = 1;

With MVCC, Transaction B can often read the version visible to its snapshot instead of waiting for Transaction A's uncommitted update.

The exact result depends on the database's isolation level and transaction timing, but the important concept is:

A reader doesn't always have to wait for a writer.

Why MVCC Matters Under Load

Imagine hundreds or thousands of transactions running concurrently.

If every SELECT had to wait for every UPDATE, and every UPDATE had to wait for readers to finish, contention would quickly become a bottleneck.

MVCC separates readers from in-progress writes by allowing transactions to work with different visible versions of the same data.

That can significantly reduce read-write contention and improve concurrency.

But MVCC isn't a magic solution to every concurrency problem.

Two transactions trying to modify the same row still need conflict handling.

That's where locks come in.

MVCC vs. Locks

A useful mental model is:

MVCC → read visibility

Locks → write conflict control

For example:

Transaction A: UPDATE account 1
       ↓
   New version
       ↓
Transaction B: SELECT account 1
       ↓
Reads a visible version according to its snapshot

But if Transaction B also tries to update the same row, the database needs to coordinate the conflicting writes.

That's when lock waiting or deadlocks can occur.

A deadlock happens when transactions form a cycle of dependencies—for example:

Transaction A → waits for B
Transaction B → waits for A

The database must detect the cycle and abort one transaction to break it.

What This Means for GBase Database

The same conceptual framework helps explain concurrency control in GBase Database.

For GBase Database(GBase 8s), understanding MVCC provides a useful starting point for understanding transaction visibility, concurrent reads, and write conflicts.

The next layer is isolation level.

Different isolation levels determine which versions a transaction can see and what consistency guarantees it receives.

So when reading GBase Database concurrency documentation, don't treat MVCC, locks, and isolation levels as three unrelated topics.

Think of them as three parts of the same system:

MVCC → versions and visibility

Locks → conflicting writes

Isolation levels → transaction consistency rules

The Takeaway

MVCC is one of the most important concepts to understand when learning database concurrency.

It explains why a database can support many concurrent readers and writers without forcing every operation to wait for every other operation.

But remember:

MVCC doesn't eliminate locks. It changes where locks are needed and reduces unnecessary read-write blocking.

Once this mental model clicks, concurrency behavior in GBase Database becomes much easier to reason about.

And when a production system starts showing lock waits, deadlocks, or unexpected transaction behavior, you'll have a much better idea of where to look.