Cassandra vs. ScyllaDB: Evolutionary Differences

Comparing design decisions, performance, and use case fit

Apache Cassandra and ScyllaDB are distributed databases designed to handle massive globally-distributed workloads. They were both created with a highly scalable architecture and both use the same CQL query language. But their priorities and design decisions have diverged quite a bit over the past decade.

From the start, there have been notable differences in fundamentals such as sharding, caching, and indexing. The differences have become more significant with the most recent releases. For example, Cassandra 5 introduced Storage‑Attached Indexes, Trie‑based Memtables & SSTables and Unified Compaction Strategy. Meanwhile, ScyllaDB added tablets elasticity (vs. vNodes), Raft, support for up to 90% storage utilization, and ZSTD dictionary-based compression for both network and storage. And both are now taking distinctly different approaches to vector search.

Join this webinar for a side-by-side analysis of the key differences and what it means for teams working with high-performance databases. We’ll cover:
- A look inside each database’s architecture and internal operations
- How performance, features, and deployment options compare
- What’s unique in each and what use cases / technical requirements benefit most from each database’s differentiators

1. Felipe Mendes, Technical Director at ScyllaDB
Guilherme Nogueira, Technical Director at ScyllaDB

Cassandra vs. ScyllaDB
Evolutionary Differences

2. Introductions
Felipe Mendes, Technical Director at ScyllaDB
+Published Author on Linux and Databases
+Helps teams solve their most challenging problems
+Years of experience with Linux and distributed systems

Guilherme Nogueira, Technical Director at ScyllaDB
+Previously Solutions Architect
+Publishing
+Streaming
+Automotive

3. Poll
How experienced are you with ScyllaDB/Cassandra?

4. Similarities and
Differences

5. ScyllaDB & Cassandra – Similarities
Distributed Peer-to-Peer Automatic Sharding Global Replication Cassandra Query Language
Wide-Column Compatible Ecosystem Anti-Entropy LSM Engine

6. Beyond Cassandra
Tablets Raft
Workload
Prioritization
Repair-based
Operations
Incremental
Compaction
SSTable
SSTable
Low
Amplification
Row-based
Cache
DynamoDB
Compatibility
Intriguing ScyllaDB Capabilities You Might Have Overlooked
Concurrency and
Rate-limiters

7. Tablets
A
C
B
C
A
B
+Abstraction: Smaller table "fragments"
+Span a contiguous token range
+Dynamically shrink/expand (geometric avg size)
+Migrated as a single unit

8. RAFT for metadata
■Strongly consistent
system.token_metadata

node A
bootstrap
bootstrap
node B
node C
Read
barrier
Read
barrier
■Fault tolerant storage

9. Workload Prioritization
No prioritization Workload Prioritization

10. Repair? Tombstones? Data Resurrection?
+Worst things a database can do:
+Lose data
+Corrupt data
+Resurrect data
+Not a problem with ScyllaDB
+We take your data seriously
+We know repair is painful
Faster, Safer Node Operations with Repair vs Streaming

11. Beyond Cassandra
Tablets Raft
Workload
Prioritization
Repair-based
Operations
Incremental
Compaction
SSTable
SSTable
Low
Amplification
Row-based
Cache
DynamoDB
Compatibility
Intriguing ScyllaDB Capabilities You Might Have Overlooked
Concurrency and
Rate-limiters

12. Incremental Compaction
A
B
...
Z
a
b
...
z
A+a
B+b
Aa
Bb
A+a
B+b
+We observed problems with legacy compaction strategies:
+STCS has high space amplification (and low write amplification)
+LCS has high write amplification (and low space amplification)
+We wanted to benefit from both approaches
+By borrowing SSTable Runs from LCS
+And applying them over size-tiers
+Merely replacing
+increasingly larger SSTables with
+increasingly longer SSTable Runs
Designing Access Methods: The RUM Conjecture

13. +ScyllaDB has a fast cache
+Efficient access & maintenance
+Thanks to collocation with replica and design
+Takes care of consistency guarantees
+Handles complexities of data and query model
Row-based Cache
memtable
RAM
Disk
Read
cache
sstable
sstable
sstable
We Compared ScyllaDB and Memcached and… We Lost?

14. +Run DynamoDB-compatible
workloads anywhere:
+on AWS
+on Google Cloud, Azure, or
+On-prem
+DynamoDB Streams, Global Tables
+Supports Load Balancing
+ScyllaDB Spark Migrator to move
data anywhere
DynamoDB-compatible
API (Alternator)
+Cassandra has no comparable feature

15. Per-Partition Rate-Limiting
Retaining Goodput with Query Rate Limiting
■Malicious/misbehaving users
■Parts of your system going awry due to bugs

The system does not have to satisfy these requests, and they should not affect the whole system too much.
■A maximum read/write rate can be set for a table.
■ScyllaDB will reject some operations in an effort to
keep the rate of successful requests under the limit.


ALTER TABLE ks.tbl
WITH per_partition_rate_limit = {
'max_writes_per_second': 100,
'max_reads_per_second': 200
};

16. Poll
How large are your clusters?

17. Comparing Performance

18. Setup
+DB Nodes
+3x AWS i4i.4xlarge (Cassandra 5.0.2, ScyllaDB 2024.2)
+16vCPU, 128GB RAM per node
+1.5TB used (~45%),
+Schema: Blob(key<10>, c0<200>, c1<200>, c2<200>, c3<200>, c4<200>)
+RF=3
+LOCAL_QUORUM
+Loader
+AWS c6in.8xlarge – Rust Latte
+Implied scheduling – see (pkolaczk/latte#120)
cassandra_latest.yml

19. Where do we start?
+Multiple iterations/settings
+Pick the best and carry out remaining tests

20. Thread Pools
+Quite a pain to fine-tune
+Single funnel
+Writes and Reads won't scale independently

21. Cache Workload
+Key cache: 2G
+Row cache: 51G
+Bummer: To use or not? :-(

22. Hot/Cold Overwrites
+Hot set: 40M rows
+Cold set: Remainder
+64% hot reads, 16% hot writes – 16% cold reads, 4% cold writes

23. Scaling

24. +ScyllaDB – Decouples topology changes from streaming
+Add nodes with time ~ 0
+Streaming happens in parallel
+Load gradually shifts, via tablet-aware drivers
+Cassandra – topology rely on streaming
+You add/remove a single node, and wait
+Then another, and wait…
+Time grows incrementally
Differences

25. +Cassandra 4.0 docs say:
+"To run any Zero Copy streaming benchmark the
stream_throughput_outbound_megabits_per_sec must be set to a really high value"
+Cassandra 5 docs say:
+"To run any Zero Copy streaming benchmark the stream_throughput_outbound must be set to a
really high value"
+Instaclustr says:
+entire_sstable_stream_throughput_outbound!
+Hint: Instaclustr is correct.
What Happened?

26. ... and then you’ve got to Cleanup
+Not needed for ScyllaDB
+Boom!

27. Bootstrap
Bootstrap Cleanup

28. Oh! By the way...
+Our Cassandra cluster got inconsistent :-(
+How to benchmark this?
+Fixed after a rolling restart
+Quite annoying

29. Demo time

30. ●Starting from 3 x i4i.4xlarge
○2TB pre-replication dataset, RF=3
○~56K ops/s for Cassandra
○~200K ops/s for ScyllaDB
●Scaling to:
○ScyllaDB: + 3 x i4i.32xlarge
○Cassandra: + 69 x i4i.4xlarge
Scaling to tackle 2M ops/s

31. Bootstrap
Bootstrap Cleanup
Scaling to tackle 2M ops/s
Bootstrap
Bootstrap Cleanup
26x
faster

32. Bootstrap
Bootstrap Cleanup
Cassandra scaling time
< 300GB transferred,
becomes linear

33. Cassandra node join process

34. ScyllaDB Scaling
●Process starts instantly and joins the cluster
●Load balancer continuously distribute tablets and load
●Client drivers are notified and route request according to tablet's movement

35. Costs

36. +Throughput
+Spiky and bounded – Batch, ETL
+ScyllaDB offers unparalleled throughput
+Latency sensitive
+Focus of our testing – Real-time and unpredictable
+ScyllaDB reacts faster to opportunities
+Storage dense – Tablets + Advanced Compression allow for up to 90% disk utilization
+Dictionary-based compression
+Data governance / Retention requirements
+ScyllaDB maximizes both disks and cache
Different savings for different workloads

37. Run df on your
Cassandra nodes
for a SURPRISE

38. Observability

39. Cassandra - DIY, Community or 3rd Party
+No centralized offer for monitoring
+Community versions available (Metrics Collector for Apache Cassandra)
+Lacks 5.0 support
+Each team comes up with their own set of dashboards and alerts
+JMX complexity
+Newer versions expose some metrics in a Prometheus friendly format bypassing JMX
+Still largely needed for Java metrics, maintenance operations
+Monitoring-as-a-Service varies in coverage and detail
+Datadog, AxiomOps, Dynatrace, New Relic

40. ScyllaDB - Out of the box monitoring
+Easy, out of the box with Scylla Monitoring stack
+Prometheus + collection rules and alerts
+Loki + alerts
+Alert Manager + alerting rules
+Grafana + powerful dashboards
+New release = new features = new dashboards
+Stay up-to-date for the latest and greatest

41. Poll
How do you monitor your clusters?
Which observability tools you use, whether custom-built or 3rd party

42. Operational
Simplicity

43. Cassandra setup and tuning
+sysctl
+ulimit | hugepages | kernel params
+disks
+scheduler | read_ahead_kb | non-rotational
+JVM ☕
+Java version | GC tuning | heap size
+cassandra.yaml
+main configuration file

44. ScyllaDB setup and tuning
+sysctl ✅ automatic
+scylla_setup
+memory, scheduling, network
+disks parameters ✅ automatic
+iotune, part of scylla_setup
+best concurrency settings to maximize disk utilization
+hardware interrupts handling ✅ automatic
+dedicated vCPUs to handle hardware interrupts via irqbalance
+allows shards to run without interferences
+jvm ✅ absent
+scylla.yaml ✅ simple changes
+usually just customized for enabling features (Alternator, encryption settings)

45. Repairs, backups
ScyllaDB Manager

Backup
Restore
Repair
Backup/restore
Medusa / K8ssandra

Repairs
Reaper

46. Vector
functionality

47. Vector
●Both implement VECTOR<float, dim> type
●Approximate Nearest Neighbour (ANN) queries
●Similar CQL syntax SELECT … ORDER BY col ANN OF vector LIMIT K

However, upon a closer look…

48. Vector - Cassandra implementation
●Implemented using Storage-Attached Index (SAI) and JVector
○Shared SSTable and compaction lifecycles
●Built on Indexes
○Susceptible to same issues
○Data locality, large partitions
●Shared data paths (storage, chunk cache)

49. Vector - ScyllaDB Cloud implementation
●External service
●In-memory data
●Rust-based service
●Leverages USearch library
●Fully-managed in the Cloud

50. Vector - ScyllaDB Cloud implementation

51. And back to
our demo

52. Wrap Up

53. +Benchmarks are complicated
+Be wary of sustained latencies on Apache Cassandra
+Measure sustained response times
+Our testing has limitations, it is impossible to test everything

+ScyllaDB outperforms Apache Cassandra 5.0 in every aspect
+Performance, Scaling, Costs
+Admin (Tip: Check out how the process to upgrade to C*5 looks like ;-)

+Plus Workload Prioritization, Alternator, frictionless monitoring, no GC, …
+Both databases evolved on their own paths
+ScyllaDB focused on maintaining high performance, scalability and vector features - all the while lowering costs
+Cassandra is built for commodity, aiming at a general purpose noSQL with use-cases with broader latency tolerance
Summary

54. Guilherme Nogueira
[email protected]
Keep Learning
Fast Scaling.
Max Efficiency. Lower Cost.
8 AM PT - 10 AM PT | 15:00 GMT - 17:00 GMT
ScyllaDB
X Cloud
ScyllaDB
University Live
LIVE LEARNNG
November 12
ONLINE | OCT 22 + 23, 2025
All Things Performance
p99conf.io
scylladb.com/events

55. Thank you
for joining us today.
@scylladb scylladb/
slack.scylladb.com@scylladb company/scylladb/
scylladb/