Scalability is a database’s ability to meet growing capacity or traffic needs without making growth an arduous operation. In ScyllaDB, it is primarily horizontal: add nodes to a distributed cluster instead of exhausting the compute and memory limits of one server. section 1.0 section 1.1.2 section 8.1
A cluster distributes data across its nodes. That distribution spreads work: traffic concentrated on one node need not affect requests served by other nodes. Replication also supports fault tolerance, while configurable replica responses let an application continue serving requests after some node losses. section 1.1.3 section 1.0
Figure 1.1 ScyllaDB is a distributed database that provides scalability and fault tolerance.
The diagram connects the two outcomes of a multi-node design: adding capacity through nodes and continuing operation despite node failures. section 1.0
Adding a node is a supported operational path, but it has consequences:
- The node joins the cluster and takes ownership of slices of data. section 1.3.2
- It receives data from other replicas until caught up; bootstrapping proceeds one node at a time. section 1.3.2
- More nodes also mean more machines to update for ScyllaDB upgrades and operating-system patches. section 1.3.2
Choosing growth over a larger server
A relational database running on one server eventually reaches its compute or memory limit. A well-designed ScyllaDB cluster can instead add a node, even when holding terabytes of data; the node receives its assigned data before contributing fully to the cluster. section 1.1.2 section 1.3.2
Scalability is tied to availability and consistency choices. ScyllaDB is positioned as availability- and partition-tolerant, favoring eventual consistency. Tunable consistency levels determine how many replicas must respond, balancing correctness and availability while the cluster grows or loses nodes. section 1.4 section 8.1
