What are common CouchDB anti-patterns and how do you avoid them?

Several CouchDB anti-patterns cause performance degradation, excessive conflicts, or runaway disk usage. Understanding them helps you design applications that work with CouchDB's architecture rather than against it.

• High-frequency counter documents — updating a single document hundreds of times per second (e.g., a page-view counter) creates a conflict storm and exponential revision chain growth. Solution: batch counter increments, use a reduce view for aggregation, or keep counters in Redis.
• Using skip for deep pagination — skip=10000&limit=20 forces a full scan of 10000 index rows per page load. Solution: use key-cursor pagination with startkey + startkey_docid.
• Querying views without indexes — running Mango _find queries without a matching json index causes full database scans. Always create a Mango index for fields used in production selectors and verify with _explain.
• Storing large binaries as attachments — attachments over ~1 MB bloat the database file and slow compaction. Use an object store (S3, MinIO) and store the URL in the document.
• Changing design documents frequently — every design document change triggers a full view index rebuild. In high-write databases this causes prolonged indexing load. Batch design document changes; test index changes in staging with realistic data volumes before deploying.
• Never running compaction — an update-heavy database that is never compacted can grow to 10-100x the size of its live data. Configure the smoosh auto-compaction daemon or schedule nightly compaction.
• Ignoring unresolved conflicts — conflicts from multi-master replication accumulate silently. Build a conflict-detection routine into your application and resolve them regularly.