Database / CouchDB Interview Questions
What is CouchDB Cluster mode (CouchDB 2.x+) and how does it differ from single-node CouchDB 1.x?
CouchDB 2.0 (released 2016) absorbed the BigCouch clustering code from Cloudant and made clustered operation the default architecture. CouchDB 3.x continues this model. A CouchDB cluster consists of multiple Erlang nodes that cooperate via a distributed hash ring (using consistent hashing) to shard and replicate data automatically.
| Aspect | CouchDB 1.x (single node) | CouchDB 2.x/3.x (cluster) |
|---|---|---|
| Horizontal scalability | None — single process, single machine | Add nodes; data shards distributed automatically |
| Fault tolerance | Single point of failure | Configurable replica count (n) per database |
| Shard distribution | No sharding — one database file | Configurable Q shards per database, each with n copies |
| Quorum reads/writes | N/A | Configurable r (read quorum) and w (write quorum) |
| Admin interface | Futon | Fauxton (modern React UI) |
| Single-node deployment | Default mode | Supported via single_node config option in 3.x |
| Database creation | PUT /db | PUT /db?q=8&n=3 (control shards and replicas) |
In a cluster, each database is split into Q shards (default 8). Each shard has n copies (default 3) stored on different nodes. When a node is added to the cluster, CouchDB uses the _cluster_setup API to join it to the ring and the rebalancing happens via standard replication. There is no external ZooKeeper or etcd dependency — cluster membership and topology are stored in the _dbs and _nodes internal databases.
More Related questions...