ScyllaDB

This page covers how ScyllaDB is built, how data flows through a write, how to model tables for it, and the trade-offs that decide whether it fits a workload.

ScyllaDB is a wire-compatible, drop-in-compatible rewrite of Apache Cassandra in C++ on the Seastar shared-nothing async framework. Founded in 2015 by KVM and OSv veterans, ScyllaDB delivers the same data model and CQL protocol as Cassandra but with dramatically higher per-node throughput and lower p99 latency — commonly 5–10× faster on equivalent hardware.

Key Features:

Shard-Per-Core Architecture. Each CPU core owns its own data shard, request queue, and TCP connection. No locks, no shared mutable state — Seastar pins threads to cores.
Cassandra-Compatible. CQL protocol, drivers, sstable format, gossip, repair tooling all match Cassandra. Existing apps switch by changing the connection string.
DynamoDB-Compatible API. Optional Alternator interface speaks DynamoDB’s wire protocol — lift-and-shift from DynamoDB without rewriting the client.
Userspace I/O Scheduler. Cooperative scheduling of disk reads, repairs, compaction, and queries — predictable p99 even under heavy mixed workloads.
Workload Prioritization. SLA tiers ensure compaction and repair never starve user-facing reads.
Single-Node Density. Routinely runs 100 TB+ per node; orders of magnitude beyond typical Cassandra footprints.

ScyllaDB vs. Cassandra:

Throughput. ScyllaDB — ~1M ops/sec per node common. Cassandra — ~100–200K typical.
p99 latency. ScyllaDB — sub-millisecond; Cassandra — tens of milliseconds during compaction.
Operational complexity. Similar — same data model, same query language, same multi-DC story.
Cluster size. ScyllaDB’s per-node density often lets a 5-node Scylla cluster replace a 30-node Cassandra cluster.

Use Cases:

High-throughput Cassandra workloads where node count or cost has become a problem.
Real-time ad-tech, gaming leaderboards, IoT telemetry — tail-latency-sensitive workloads.
DynamoDB migrations seeking open-source alternative without rewriting the client (Alternator API).
Multi-region deployments where Cassandra’s p99 jitter under repair is unacceptable.

1. Shard-per-core architecture

Each CPU core runs an independent shard that owns a slice of the node's token range, its own memtables, SSTables, cache and I/O queue. Cores do not share data structures or locks; when one shard needs work done by another, it sends a message. Shard-aware drivers compute which core owns a partition and connect directly to it, avoiding a cross-core hop. ScyllaDB also schedules its own I/O and CPU between foreground queries and background compaction, instead of relying on the operating system page cache and JVM garbage collector as Cassandra does.

2. Write and read path

The coordinator node hashes the partition key to a token and forwards the write to the replicas that own it. Each replica appends to its commit log and updates an in-memory memtable, then acknowledges. Memtables flush to immutable SSTables, and compaction merges SSTables to reclaim space and drop expired tombstones. Reads consult the row cache, then the memtable, then SSTables filtered by bloom filters. The consistency level (ONE, QUORUM, LOCAL_QUORUM, ALL) decides how many replicas must answer.

3. Data modelling example

Like Cassandra, ScyllaDB is query-first: design one table per access pattern, choose a partition key that spreads load and bounds partition size, and use clustering columns for sort order within the partition.

CREATE KEYSPACE iot WITH replication =
  {'class': 'NetworkTopologyStrategy', 'dc1': 3};

CREATE TABLE iot.readings (
  device_id text,
  day       date,
  ts        timestamp,
  temp      double,
  PRIMARY KEY ((device_id, day), ts)
) WITH CLUSTERING ORDER BY (ts DESC)
  AND default_time_to_live = 2592000;

-- Latest 10 readings for a device today: a single-partition read
SELECT ts, temp FROM iot.readings
WHERE device_id = 'd-17' AND day = '2026-10-01' LIMIT 10;

from cassandra.cluster import Cluster   # scylla-driver is API-compatible
session = Cluster(["127.0.0.1"]).connect("iot")
stmt = session.prepare("INSERT INTO readings (device_id, day, ts, temp) VALUES (?,?,?,?)")
session.execute(stmt, ("d-17", "2026-10-01", "2026-10-01 12:00:00", 21.4))

Bucketing the partition key by day keeps any single partition from growing without bound, which is the most common modelling mistake on wide-column stores.

4. When to use it

Need	ScyllaDB	Alternative
High write throughput, predictable low latency at scale	Strong fit	Cassandra
Ad-hoc joins and analytics	Poor fit	PostgreSQL, a warehouse
Multi-row ACID transactions	Lightweight transactions only	Relational DB, FoundationDB
DynamoDB-compatible API	Alternator	DynamoDB

Operationally, ScyllaDB clusters are usually sized by cores and disk rather than by heap tuning, since there is no JVM. It ships tooling for repair, backup and monitoring (Scylla Manager and a Prometheus/Grafana stack), and repairs still need to run regularly so that replicas converge after node outages. Because it is wire-compatible with Cassandra, existing CQL drivers, tools such as cqlsh, and data models generally move over without changes, which makes a proof of concept cheap to run against real traffic.

5. Pitfalls

Hot partitions: a low-cardinality key concentrates load on one shard.
Unbounded partitions that grow to gigabytes.
Heavy deletes producing tombstones that slow reads until compaction.
Relying on ALLOW FILTERING or secondary indexes for primary access paths.