Differences from Cassandra

The data model, CQL and cluster concepts are shared. The differences are in implementation and operations.

Tooling

nodetool exists in ScyllaDB with most of the same subcommands, implemented over the REST API rather than JMX. Some options differ or are unsupported, so scripts should be tested rather than assumed to transfer.

Monitoring changes more substantially: anything built on JMX metric names needs rewriting against ScyllaDB's Prometheus metric names. The vendor ships a monitoring stack with prebuilt dashboards, which is the fastest route.

Behavioural differences worth testing

• Self-tuning schedulers replace manual throughput settings. Configuration that pins compaction throughput has no equivalent meaning, and forcing limits can work against the scheduler.
• Memory management is explicit rather than heap-based. There is no equivalent of JVM heap tuning, and out-of-memory behaviour differs.
• Some features lag or lead. Materialized views, CDC, secondary index behaviour and specific CQL functions have differed between the projects at various points. Verify the features you rely on against the exact version.

Operational implications of fewer, larger nodes

Running the same workload on fewer machines changes more than cost:

• A node loss removes a larger share of the cluster. Plan replication factor and rack placement accordingly.
• Streaming a replacement node moves more data, so bootstrap and repair take longer per node.
• Per-shard imbalance becomes more visible, because there are more shards per node and one hot shard is a smaller fraction of node capacity but a full core.