CouchDB

Most databases treat replication as plumbing under a single-writer model. CouchDB inverts the relationship: replication is the product, and single-writer semantics are what got sacrificed to make it work. Every document carries a revision token, every node can accept writes, and any two copies of a database can sync bidirectionally. If your problem is “data must keep flowing between nodes that are frequently disconnected”, that is exactly what CouchDB was built for.

Documents and MVCC revisions

Data lives as JSON documents in databases (the CouchDB word for a table-like namespace), addressed by _id. Every write produces a new revision: the _rev token on each document is a version vector, and a write must carry the current _rev or the update is rejected with a 409 conflict.

This is MVCC exposed to the application rather than hidden in the engine:

• Single-document atomicity only. One document writes atomically; there are no multi-document transactions. Money-moving-style invariants across documents are the application’s problem.
• Conflicts are a normal state, not an error. Two nodes that edited the same document while disconnected produce conflict branches. CouchDB deterministically picks a “winner” for reads but keeps the losing revisions - and it is the application’s job to merge or delete them.

The replication protocol

Replication is incremental, peer-to-peer, and bidirectional: source and target diff their _changes feeds, transfer only missing revisions, and checkpoint progress so a sync can resume after disconnection. Any two CouchDB-compatible endpoints can sync - server to server, or server to PouchDB running in a browser or mobile app.

This is the feature with no real rival. An offline-first field app can write locally for days, then sync everything when connectivity returns - with conflicts surfaced rather than hidden.

Querying

• Mango: declarative JSON query syntax ({ "selector": {...} }) over JSON indexes - the everyday query path.
• Map-reduce views: JavaScript map/reduce functions materialized as B-tree indexes, updated incrementally as documents change.
• _changes feed: a persistent, ordered log of document changes - the primitive both replication and many integrations are built on.

Clustering and consistency

CouchDB 3.x runs clustered (q-sharded databases across nodes) or standalone. There is no leader: every node accepts writes for every document. Consistency is therefore deliberately eventual - quorum parameters (n, r, w) bound each operation, and inter-node replication keeps replicas converging. Expect stale reads by design, not by accident.

Operations

Operationally CouchDB is gentle: HTTP API, small footprint, log files, compaction is automatic with tuneable windows. Two chores are real: conflict hygiene (unresolved conflict branches accumulate and must be merged or deleted by application code) and view index maintenance (rebuilding a large design-doc view is heavy).

What actually breaks

• Unbounded conflict accumulation - a hot document edited on many nodes accumulates revision branches; reads stay correct-ish but storage and sync costs grow. Converge on a merge policy.
• Multi-document invariants in the application - “debit A and credit B atomically” has no engine guarantee; design around it or pick another database.
• Treating Sync as backup: replication copies current state including deletions; it is not a point-in-time backup.

Where CouchDB is the wrong choice

If you need multi-document transactions, ad-hoc relational queries, or strong consistency as a default, this is the wrong engine - MongoDB covers the document model with transactions and a real query planner. CouchDB earns its place exactly where multi-master sync is a first-class requirement; elsewhere you are paying its compromises for a feature you do not use.