ScyllaDB - Fastest write-heavy NoSQL Database, compare with Cassandra
Here are my notes after exploring ScyllaDB architecture and comparing it with Cassandra.
Ref:
-
Product: https://www.scylladb.com/product/
-
Open-source: https://github.com/scylladb/scylladb
1. Concepts
| Term | Idea |
|---|---|
| Partition Key | Determines which node (and shard) owns the data. |
| Clustering Key | Sorts data inside one partition. |
| Memtable | In-memory write buffer. |
| SSTable | Immutable sorted file persisted to disk. |
| Compaction | Merge multiple SSTables into a larger one. |
| Consistent Hash Ring | Maps partition keys to nodes. |
| Replication Factor | Number of copies stored across the cluster. |
| Shard-per-Core | Each CPU core owns one shard. |
| Seastar | Async runtime used by ScyllaDB. |
2. Main Idea
ScyllaDB is not a new data model.
It keeps Cassandra’s distributed architecture while replacing the execution engine.
Cassandra
Java + Thread Pool
↓
Shared Memory
==============================
ScyllaDB
C++ + Seastar
↓
Shard-per-Core
Think of it as
Cassandra architecture + modern execution engine.
3. Cassandra vs ScyllaDB
Same
Both databases have
- Consistent Hash Ring
- Partition Key
- Clustering Key
- Memtable
- SSTable
- Replication
- CQL
- Horizontal Scaling
Different
| Cassandra | ScyllaDB |
|---|---|
| Java | C++ |
| Thread Pool | Async Event Loop |
| Shared Heap | Dedicated Memory per CPU |
| Thread Synchronization | Message Passing |
| JVM Garbage Collection | No JVM |
| OS Scheduler | Seastar Scheduler |
4. Why is ScyllaDB faster?
The biggest innovation is
Shard-per-Core
Instead of
100 Threads
↓
8 CPUs
Scylla uses
CPU0
↓
Shard0
------------
CPU1
↓
Shard1
------------
CPU2
↓
Shard2
Each CPU owns
- memory
- cache
- scheduler
- memtable
No locks between CPUs.
Request Flow
Application
↓
Partition Key
↓
Hash()
↓
Node
↓
Shard
↓
CPU
↓
Memtable
Every request for the same key always reaches the same CPU.
5. Memtable & SSTable
Step 1
Write
Alice = 10
↓
Memtable (RAM)
Alice = 10
Step 2
More writes
Alice = 10
Bob = 5
John = 7
↓
Memtable
Step 3
Memtable becomes full
↓
Flush
↓
SSTable-1
Alice = 10
Bob = 5
John = 7
Step 4
New writes
Alice = 11
↓
New Memtable
Alice = 11
Notice
SSTable-1 is never modified.
Step 5
Flush again
SSTable-1
Alice = 10
Bob = 5
------------
SSTable-2
Alice = 11
Step 6
Background Compaction
SSTable-1
+
SSTable-2
↓
Merge
↓
New SSTable
Alice = 11
Bob = 5
Complete Flow
Write
↓
Memtable (RAM)
↓
Flush
↓
SSTable
↓
Compaction
↓
Optimized SSTable
6. Why doesn’t ScyllaDB need locks?
Traditional database
Thread A
Update
||
Thread B
Read
Need mutex.
Scylla
Shard
↓
Event Loop
↓
Update
↓
Read
↓
Update
Only one callback executes at a time on a shard.
No mutex required for the hot path.
7. Does this reduce concurrency?
Initially I thought:
One CPU owns one shard.
Doesn’t that reduce concurrency?
Actually,
it only limits concurrency for the same partition.
Example
Alice
↓
CPU2
Bob
↓
CPU7
Charlie
↓
CPU0
Millions of different partition keys are distributed across CPUs.
The whole machine still executes requests in parallel.
Only a hot partition becomes a bottleneck.
8. Why not design Cassandra like this?
Because Cassandra was designed around 2007.
Typical servers then
- 2~4 CPU cores
- HDD
- JVM thread pools
ScyllaDB was designed later for
- 64+ CPU cores
- NVMe SSD
- Asynchronous programming
The biggest innovation is not simply
One CPU per shard
It is redesigning the entire runtime around that idea.
9. Architecture Summary
Application
↓
Partition Key
↓
Consistent Hash Ring
↓
Node
↓
Shard (CPU)
↓
Memtable
↓
Flush
↓
SSTable
↓
Compaction
↓
Replication
10. Learning Notes
-
ScyllaDB is Cassandra-compatible, not because it shares code, but because it implements the same APIs (CQL), storage model, and distributed architecture.
-
The biggest performance gain comes from Shard-per-Core, eliminating shared-memory contention.
-
Memtable → SSTable → Compaction is the write path of every LSM Tree database.
-
The event loop serializes operations within a shard, removing the need for traditional mutexes on the hot path.
-
ScyllaDB optimizes the execution engine, while Cassandra defines the distributed data model.
