Skip to main content
UploadLanguage (EN)Support
BusinessMobileSocial MediaMarketingTechnologyArt & PhotosCareerDesignEducationPresentations & Public SpeakingGovernment & NonprofitHealthcareInternetLawLeadership & ManagementAutomotiveEngineeringSoftwareRecruiting & HRRetailSalesServicesScienceSmall Business & EntrepreneurshipFoodEnvironmentEconomy & FinanceData & AnalyticsInvestor RelationsSportsSpiritualNews & PoliticsTravelSelf ImprovementReal EstateEntertainment & HumorHealth & MedicineDevices & HardwareLifestyle
ScyllaDB, profile picture
Uploaded byScyllaDB
8 views

Cassandra vs ScyllaDB: Evolutionary Differences

Join Guilherme Nogueira, ScyllaDB Technical Director, for a live 25-min walkthrough of the technical differences and what they mean for different types of high-performance database workloads.

Technology◦
Download to read offline
Cassandra vs ScyllaDB: Evolutionary Differences The webinar will begin shortly…
Guilherme Nogueira, Technical Director at ScyllaDB Cassandra vs. ScyllaDB Evolutionary Differences
Introductions Guilherme Nogueira, Technical Director + A.K.A. Gui + Previously Solutions Architect + Publishing + Streaming + Automotive
Poll How experienced are you with ScyllaDB/Cassandra?
Similarities and Differences
ScyllaDB & Cassandra – Similarities Distributed Peer-to-Peer Automatic Sharding Global Replication Cassandra Query Language Wide-Column Compatible Ecosystem Anti-Entropy LSM Engine
Beyond Cassandra Intriguing ScyllaDB Capabilities You Might Have Overlooked Raft Workload Prioritization Repair-based Operations Incremental Compaction SSTable SSTable Low Amplification Row-based Cache DynamoDB Compatibility Concurrency and Rate-limiters Tablets
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
Workload Prioritization No prioritization Workload Prioritization
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
Incremental Compaction A B ... Z a b ... z A+a B+b A a B b 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
+ 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?
+ Run DynamoDB-compatible workloads anywhere: + AWS + Google Cloud, Azure + 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
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 };
Poll How large are your clusters?
Comparing Performance
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
Cache Workload + Key cache: 2G + Row cache: 51G + Bummer: To use or not? :-(
Hot/Cold Overwrites + Hot set: 40M rows + Cold set: Remainder + 64% hot reads, 16% hot writes – 16% cold reads, 4% cold writes
Scaling
+ 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
... and then you’ve got to Cleanup + Not needed for ScyllaDB + Boom!
Bootstrap Bootstrap Cleanup
Oh! By the way... + Our Cassandra cluster got inconsistent :-( + How to benchmark this? + Fixed after a rolling restart + Quite annoying
Achieving 2M ops/s
+ 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
Bootstrap Bootstrap Cleanup Scaling to tackle 2M ops/s Bootstrap Bootstrap Cleanup 26x faster
Bootstrap Bootstrap Cleanup Cassandra scaling time < 300GB transferred, becomes linear
Cassandra node join process
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
Costs
+ 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
Run df on your Cassandra nodes for a SURPRISE
Wrap Up
+ 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
All Things Performance A ScyllaDB Community Virtual Event | OCTOBER 21 + 22, 2026 Register now at p99conf.io
Thank you for joining us today. @scylladb scylladb/ slack.scylladb.com @scylladb company/scylladb/ scylladb/