What is the CouchDB storage engine (B-tree) and how does its append-only write work?

CouchDB stores each database as a single file on disk structured around an append-only B-tree. There are multiple B-trees per database file: one for documents and one for each view index. Every write — new document, updated revision, or index update — is appended to the end of the file. The existing bytes are never modified in place. New B-tree nodes are written at the end, and a small database header near the end of the file is atomically updated to point to the new B-tree root.

Three important consequences of this design:

• Crash safety without a WAL — a crash mid-write at most leaves an incomplete append at the tail. On restart, CouchDB scans backward for the last valid database header and discards any partial write. No separate Write-Ahead Log is needed.
• No read locks — the previous B-tree root remains valid until the header atomically advances. Concurrent readers always see a consistent snapshot, which is the physical basis of MVCC.
• Simple fsync durability — CouchDB calls fsync after writing each committed transaction before returning 201 to the client, guaranteeing data is on stable storage.

The trade-off: the file grows with every write because old revisions accumulate as unreachable B-tree nodes. This is why compaction is essential in write-heavy workloads. In CouchDB 3.x each shard of a clustered database is its own append-only file following the same model.