Download to read offline
Uploaded byScyllaDB
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
More Related Content
Similar to Cassandra vs. ScyllaDB: Evolutionary Differences
Cassandra vs. ScyllaDB: Evolutionary Differences
- 1. Felipe Mendes, TechnicalDirector at ScyllaDB Guilherme Nogueira, Technical Director at ScyllaDB Cassandra vs. ScyllaDB Evolutionary Differences
- 2. Introductions Felipe Mendes, TechnicalDirector 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 areyou with ScyllaDB/Cassandra?
- 4.
- 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 IntriguingScyllaDB Capabilities You Might Have Overlooked Concurrency and Rate-limiters
- 7. Tablets A C B C A B + Abstraction: Smallertable "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 prioritizationWorkload Prioritization
- 10. Repair? Tombstones? DataResurrection? + 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 IntriguingScyllaDB Capabilities You Might Have Overlooked Concurrency and Rate-limiters
- 12. Incremental Compaction A B ... Z a b ... z A+a B+b A a 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 hasa 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 workloadsanywhere: + 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 Goodputwith 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 areyour clusters?
- 17.
- 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 westart? + Multiple iterations/settings + Pick the best and carry out remaining tests
- 20. Thread Pools + Quitea pain to fine-tune + Single funnel + Writes and Reads won't scale independently
- 21. Cache Workload + Keycache: 2G + Row cache: 51G + Bummer: To use or not? :-(
- 22. Hot/Cold Overwrites + Hotset: 40M rows + Cold set: Remainder + 64% hot reads, 16% hot writes – 16% cold reads, 4% cold writes
- 23.
- 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.0docs 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 thenyou’ve got to Cleanup + Not needed for ScyllaDB + Boom!
- 27.
- 28. Oh! By theway... + Our Cassandra cluster got inconsistent :-( + How to benchmark this? + Fixed after a rolling restart + Quite annoying
- 29.
- 30. ● Starting from3 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 totackle 2M ops/s Bootstrap Bootstrap Cleanup 26x faster
- 32. Bootstrap Bootstrap Cleanup Cassandra scalingtime < 300GB transferred, becomes linear
- 33. Cassandra node joinprocess
- 34. ScyllaDB Scaling ● Processstarts 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.
- 36. + Throughput + Spikyand 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 onyour Cassandra nodes for a SURPRISE
- 38.
- 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 - Outof 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 youmonitor your clusters? Which observability tools you use, whether custom-built or 3rd party
- 42.
- 43. Cassandra setup andtuning + 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 andtuning + 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.
- 47. Vector ● Both implementVECTOR<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 - Cassandraimplementation ● 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 - ScyllaDBCloud implementation ● External service ● In-memory data ● Rust-based service ● Leverages USearch library ● Fully-managed in the Cloud
- 50. Vector - ScyllaDBCloud implementation
- 51. And back to ourdemo
- 52.
- 53. + Benchmarks arecomplicated + 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. Keep Learning Fast Scaling. MaxEfficiency. 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 joiningus today. @scylladb scylladb/ slack.scylladb.com @scylladb company/scylladb/ scylladb/