How does CouchDB handle large document sets — what are the performance trade-offs of large vs many small documents?

CouchDB does not have a hard document size limit (the default max_document_size is 4GB), but the performance trade-offs between storing data as a small number of large documents versus many small documents are significant.

Large documents (e.g., one document per entity with thousands of nested items):

• Every update requires a full rewrite of the document, even if only one nested field changed. This amplifies write I/O and revision chain growth.
• Replication transfers the entire document body on every change. For a 5MB document that changes frequently, this saturates replication bandwidth quickly.
• MVCC conflicts are more likely and more costly to merge because the entire body must be transferred and compared.
• Reading the document always loads the full JSON, even if only one field is needed (CouchDB has no projection at the storage layer — Mango fields projection happens after the document is loaded).

Many small documents (one document per event/record):

• Updates are small and cheap; conflicts affect only the specific document touched.
• Replication is incremental — only changed documents are transferred.
• Mango and view queries can filter and paginate efficiently.
• The trade-off: each document has overhead (~200 bytes for metadata). A database with 100 million tiny 50-byte documents will have metadata overhead larger than the data itself.

The recommended pattern: keep documents to a natural entity size (an order with its line items, not an order with the entire customer history). Avoid designs that require updating a single document at a rate faster than ~100 writes/second — high-frequency counters belong in Redis, not in a CouchDB document.