ScyllaDB
Cassandra rebuilt in C++ on a shared-nothing sharded architecture: the same model, lower latency.
ScyllaDB reimplements the Cassandra wide-column model in C++ on a shared-nothing architecture: each core owns its own shard of memory, SSTables, and network queues, with no cross-core locks or coordination. Fully compatible with Cassandra drivers and CQL, targeting single-digit-millisecond p99 at high throughput.
Shared-nothing shards
One shard per CPU core, each with private memory, cache, commit log slice, and network queues. Requests never cross cores — no locks, no atomics on the hot path.
CQL-compatible
Speaks Cassandra Query Language and the Cassandra wire protocol: drivers migrate by swapping endpoints, schema and tools carry over.
Self-tuning compaction
Compaction strategy switches by workload shape (size-tiered for write-heavy, incremental for read-heavy) and adapts without manual threshold tuning.
IO scheduler
A reactor-level IO scheduler shares disk bandwidth across shards by priority class — compaction cannot starve the read path.
Why rebuild Cassandra in C++?
Cassandra runs one JVM with shared heaps, GC pauses, and cross-core coordination on the hot path. ScyllaDB applies the seastar framework: thread-per-core, poll-mode IO, and per-core ownership — the same CQL semantics with dramatically lower tail latencies and predictable behavior under saturation.
For the data model nothing changes: partition key, clustering columns, tunable consistency, tombstones, compaction. The difference is execution architecture — which is the lesson of this exhibit: the same data model can ride radically different engines.
CREATE TABLE metrics (
series_id uuid,
ts timestamp,
value double,
PRIMARY KEY (series_id, ts)
);
Reading the latency story
The latency story is the pitch: shared-nothing cores mean p99 stays flat as throughput climbs — the tail does not diverge from the median under load the way GC-based engines do.
Read the percentiles, not the average: p50 and p99 together reveal queueing, compaction pressure, and shard imbalance. The IO scheduler keeps compaction from starving reads, which is what keeps that p99 line flat.
Diagrams
[caption] Shared-nothing: ownership of memory and disk queues is per-core.
A request lands on one core, hops to the shard owning the partition key, and follows the LSM loop entirely within that core — no cross-core locks.
Per-shard SSTable counts stay balanced because partition tokens map evenly to cores — imbalance is a token, not a tuning, problem.
[caption] Illustrative per-shard SSTable tiers on a 4-core node.
Per-shard SSTable counts stay balanced because partition tokens map evenly to cores — imbalance is a token, not a tuning, problem.