What is MVCC (Multi-Version Concurrency Control) in CouchDB and how does it handle write conflicts?

MVCC in CouchDB means every write produces a new immutable version of the document instead of modifying data in place. Readers always see a consistent snapshot from the moment they start reading; no read locks are acquired. The append-only B-tree storage engine keeps old revisions on disk until compaction removes them.

The conflict mechanism works like this: when two concurrent writers both read a document at revision 2-abc and both try to PUT with _rev: "2-abc", only the first writer to reach the storage engine succeeds. The second receives HTTP 409 Conflict immediately.

# Both clients read revision 2-abc...

# Client A succeeds:
curl -X PUT http://localhost:5984/db/doc1 \
  -d '{"_rev":"2-abc","value":10}'
# 201: {"ok":true,"rev":"3-xyz"}

# Client B fails — same _rev already superseded:
curl -X PUT http://localhost:5984/db/doc1 \
  -d '{"_rev":"2-abc","value":20}'
# 409: {"error":"conflict","reason":"Document update conflict."}

The standard resolution is a read-modify-write retry loop: on 409, re-read the document to get the latest _rev, apply the business logic to the fresh body, and retry the PUT. This is optimistic locking enforced at the protocol level.

In multi-master replication scenarios, two nodes can independently accept writes to the same document. These produce open conflicts stored as sibling revisions, visible via ?conflicts=true. The application must explicitly merge or discard the losing revision to resolve them (see Q27).