ScyllaDB is a distributed wide-column NoSQL database: data is spread and replicated across multiple nodes rather than kept on one server. It is designed for horizontal scalability and fault tolerance, while remaining compatible with Apache Cassandra’s API, query language, on-disk format, and hash-ring architecture. section 1.1.3 section 1.2.3
Unlike a relational database, ScyllaDB does not use joins or relational modeling as its default. Its tables can have arbitrarily wide rows, and a schema is defined up front so the database can distribute data predictably. Model data around the queries an application needs, especially queries that can target a partition key. section 1.1 section 1.1.3 section 1.2.5
Figure 1.1 ScyllaDB is a distributed database that provides scalability and fault tolerance.
A cluster of nodes provides capacity beyond a single machine and keeps serving requests when configured replicas remain available. section 1.0
Any node can receive a request. It determines the row’s owner through the hash ring and forwards work to the relevant nodes. Replication stores a row on multiple nodes; the replication factor determines how many copies exist. Consistency levels then set how many replicas must acknowledge a read or write. section 1.2.1
Consistency is tunable, so each query can trade availability against the chance of stale or inconsistent results:
- ALL requires every replica. It maximizes agreement but tolerates no replica failure. section 1.2.1
- QUORUM requires a majority of replicas. With three replicas, two responses succeed and one failure is tolerated. section 1.2.1
- ONE requires one replica. It remains available through more failures but increases the chance of inconsistent results. section 1.2.1
This design favors availability and partition tolerance, with eventual consistency rather than relational ACID guarantees. It uses a BASE model: data converges toward correctness over time. That trade-off can make writes simpler and faster, but applications must account for weaker consistency when correctness requires it. section 1.2.2 section 8.1
Query restaurant reviews by partition
For a food-review table partitioned by restaurant, query reviews for “Ernie’s Eats” with restaurant in the WHERE clause. The coordinator can locate that partition and contact its owner and replicas. A query across every restaurant, or one filtered only by ordered_at, can involve many partitions and is not a scalable production pattern. section 2.3.2
Scaling is usually an operational matter of adding a node: it joins the cluster, takes ownership of data ranges, and receives streamed replicas while bootstrapping. A failed node can likewise be replaced; replicas stream its data to the replacement. More nodes add upgrade and maintenance work, so the operational cost is part of the choice. section 1.3.1 section 1.3.2
Choose ScyllaDB when an application needs growth, distributed reads, and graceful handling of node loss. A small or rapidly changing application may find its modeling and operational overhead excessive; workloads needing strong transactional isolation, such as financial operations, may prefer a relational database. section 1.2.7 section 1.3.3
