You can scale Couchbase services independently across different nodes, meaning you don’t have to scale your entire cluster just because your data service is getting hammered.
Let’s see this in action. Imagine you have a Couchbase cluster with a few nodes, and you’ve assigned specific services to each:
{
"cluster": {
"name": "my-couchbase-cluster",
"nodes": [
{
"hostname": "cb-node-1",
"services": [
"kv",
"index",
"query"
]
},
{
"hostname": "cb-node-2",
"services": [
"kv",
"index",
"query"
]
},
{
"hostname": "cb-node-3",
"services": [
"kv",
"index",
"query"
]
}
]
}
}
Now, your application is experiencing a surge in read queries. The query service on your existing nodes is struggling. With multi-dimensional scaling, you don’t need to add more nodes that also run kv and index if you don’t need them. Instead, you can add a new node specifically for the query service:
{
"cluster": {
"name": "my-couchbase-cluster",
"nodes": [
{
"hostname": "cb-node-1",
"services": [
"kv",
"index",
"query"
]
},
{
"hostname": "cb-node-2",
"services": [
"kv",
"index",
"query"
]
},
{
"hostname": "cb-node-3",
"services": [
"kv",
"index",
"query"
]
},
{
"hostname": "cb-query-node-4",
"services": [
"query"
]
}
]
}
}
This new node cb-query-node-4 will only run the query service. Couchbase’s intelligent data distribution and request routing will automatically start sending a portion of your query traffic to this new node, alleviating the load on the original nodes. You can repeat this process, adding more query nodes, or kv nodes if your write throughput is the bottleneck, or index nodes if your index lookups are slow, all without over-provisioning other services.
The core problem this solves is the inefficiency of traditional monolithic database scaling. In older systems, if you needed more query performance, you’d have to add an entire new database server, which also came with its own copy of the data and indexing capabilities, leading to wasted resources and increased management overhead. Multi-dimensional scaling decouples the scaling of different functional units within Couchbase. Each service (kv, index, query, fts, analytics, eventing, backup) can be scaled independently by adding nodes dedicated to that service. This allows for highly granular resource allocation, ensuring you’re only scaling what you actually need, when you need it.
Internally, Couchbase achieves this by having each service run as a distinct process. When you add a node and assign it a specific service, you’re essentially adding more capacity for that particular process within the cluster. The cluster manager (which runs on every node) then orchestrates the distribution of data (for kv and index) and the routing of requests across the available service instances. For example, the kv service is responsible for storing and retrieving documents. If you add more kv nodes, Couchbase will rebalance the data partitions (vBuckets) across the new nodes to distribute the storage and I/O load. Similarly, when you add a query node, the cluster manager will inform the query clients (like your application SDK) about the new query service endpoint, and they will start sending queries to it.
The exact levers you control are the services list when provisioning or modifying nodes. You can assign one or more services to a node. For example, a node could have kv and index services, or just query and analytics, or even all services if you’re running a small, single-node cluster for development. The key is that Couchbase doesn’t require a node to run a specific set of services; it’s flexible. This flexibility extends to rebalancing. If you remove a node, Couchbase automatically rebalances the services that were running on that node to other available nodes of the same service type.
When you assign multiple services to a single node, like kv, index, and query, Couchbase internally manages the resource allocation for each service on that node. It uses lightweight processes and efficient inter-process communication to ensure that, for instance, the kv service doesn’t hog all the CPU if the query service is busy, and vice-versa, up to the physical limits of the node. This is managed by the Couchbase internal scheduler and resource manager, which are aware of the different service types and their typical resource needs.
The next concept to explore is how data is distributed across these independently scaled kv nodes using vBuckets.