Shard-per-Core Architecture

ScyllaDB applies the shared-nothing principle inside a single machine. Each CPU core is a shard: it owns a partition of the node's data, has its own memory allocation, its own scheduler and its own network queues.

Why it matters

• No locks on the data path. A shard's data is touched by exactly one thread, so there is no contention and no cache-line bouncing between cores.
• Predictable scaling with core count. Throughput scales close to linearly with cores, because cores do not coordinate.
• Explicit CPU accounting. Compaction, repair and streaming run on the same shard as the traffic they compete with, so the scheduler can meter them against user requests instead of guessing at a global throughput limit.

The token range a node owns is subdivided across its shards, so a partition maps to one node and, on that node, to one core.

Consequences for clients

The same rule as Cassandra applies with more force: a hot partition now saturates a single core, not just a node. See Hot Partitions.

Consequences for operations

• CPU count is a topology decision. Changing the core count changes the shard layout, so resizing an instance is not a transparent operation.
• Memory is divided among shards. A shard with an unusually large working set cannot borrow memory from an idle sibling.
• perftune.py matters. ScyllaDB ships tooling that configures IRQ affinity, network queue steering and CPU pinning. Running without it leaves substantial performance unclaimed.

scylla_setup                  # guided host configuration on install
perftune.py --tune net --tune disks --nic eth0 --mode sq_split

Reading per-shard state

nodetool status
nodetool cfstats keyspace.table
 
# Per-shard metrics are exposed on the Prometheus endpoint.
curl -s localhost:9180/metrics | grep scylla_reactor_utilization

scylla_reactor_utilization per shard is the metric to watch. One shard near saturation while others are idle means an imbalanced workload — almost always a hot partition or a low-cardinality partition key.