What is the impact of reducing shard and replica counts on low-traffic CouchDB 3.x storage?

Optimizing Storage for Low-Traffic Workloads

In a CouchDB 3.x environment hosting low-traffic databases, operational costs are primarily driven by disk utilization and compute overhead. By default, CouchDB creates databases with clustered semantics, often utilizing a shard count (q) and replica factor (n) designed for high availability and scalability.

For small datasets with minimal request volume, these defaults may lead to unnecessary file proliferation and increased compaction overhead. While reducing q and n can lower the storage footprint and reduce the coordination effort during writes, these settings are typically fixed at the time of database creation.

There is uncertainty regarding the optimal balance between resource savings and data durability when scaling down to a single-node or low-replica configuration for non-critical workloads.

• Does lowering the shard count (q) significantly reduce the frequency and resource intensity of the compaction process for tiny databases?
• What are the specific durability trade-offs when reducing the replica factor (n) to 1 in a low-traffic environment?