If You Think ScyllaDB Is Just Cassandra in C++, Look Again

ScyllaDB is often described as Cassandra rewritten in C++. The original proposition was straightforward: keep the data model and CQL ecosystem, replace the JVM with Seastar, asynchronous I/O and a shard-per-core architecture. Use multicore hardware efficiently, avoid garbage-collection pauses and keep latency predictable.

In consulting work, “faster Cassandra” is still how teams usually introduce a ScyllaDB migration. But placement, cluster management and even the storage engine are changing:

The release overview below covers ScyllaDB through 2026.2, where Strongly Consistent Tables and online vNode-to-Tablet migration are experimental. Logstor is discussed separately as development work.

The first difference was inside a node

Both Cassandra and early ScyllaDB distributed data across nodes using a token ring. ScyllaDB added sharding inside each node, using Seastar's shard-per-core architecture.

A shard is the part of ScyllaDB running on one CPU core, with its own data and resources. It serves many CQL partitions, each grouping rows with the same partition key. Shards communicate explicitly, keeping most work local to the core. See ScyllaDB's shard-per-core overview.

Shard-aware drivers route requests toward the core responsible for the data, avoiding an extra cross-core hop. Tablet-aware drivers also learn tablet locations from routing information returned by the server and update their caches as placement changes. Older shard-aware drivers still work, with less efficient routing.

Tablets make data placement specific to each table

With vNodes, a partition key hashes to a token, and the cluster's token ownership determines placement. Each physical node owns multiple ranges. Tables share that underlying ownership map, with replication settings determining the replicas.

A tablet represents a token range for one table. It has replicas placed on particular nodes and shards. Each table can divide the token space differently. One shard can host many tablet replicas.

For example, an events table might contain several terabytes while a customers table contains a few gigabytes. They do not need identical distribution granularity. As events grows, its tablets can split, and the resulting tablets can move independently. The smaller table can keep fewer tablets.

The balancer can move a tablet replica to another node or another shard within a node. Splitting and merging let the database adjust the size of the units it manages. Token ranges still exist; ownership is now managed at the table level.

There is an important limit: a single CQL partition belongs to one tablet. Splitting a tablet divides a range of partitions, not the contents of one partition. A poor partition key can therefore still produce an oversized or hot partition. Tablets give the database more placement options, but they cannot distribute that one partition across independent tablets for you.

What changes when you add capacity?

Suppose you add a larger machine during a hardware refresh. With vnode placement, you need the token allocation to give it an appropriate share of the data. With tablets, the balancer can move individual tablet replicas onto it and continue adjusting placement as the cluster changes.

Capacity-aware balancing in 2026.1 uses tablet sizes and node capacity to address uneven disk utilisation: one node filling up while others still have space.

Mixed hardware becomes more practical, but “capacity-aware” does not mean every resource will be used evenly. Disk space, CPU capacity and request traffic are different constraints. A node with plenty of free disk may already be busy serving a popular partition. I would still measure the actual workload before assuming that a hardware refresh will produce proportional gains.

Tablet migration also uses file-based streaming. Moving SSTables avoids some of the work needed to decode and re-encode their contents during rebalancing.

Tablets are established; migration still needs attention

The rollout happened over several releases:

That last distinction matters for an existing deployment. Tablets being the default for new clusters does not mean that upgrading converts every existing vnode-based table. The placement model of your current tables and the supported migration procedure deserve a separate check.

Raft gives schema and topology changes an order

Gossip is useful for spreading observations about nodes. Concurrent schema changes require something more precise: agreement on which change comes first.

ScyllaDB's Raft documentation describes how the earlier schema mechanism could lose changes when nodes reconciled conflicting updates using timestamps. Raft-based schema management, enabled by default for new clusters in 5.2, puts those operations through a consensus log.

Topology management followed. Bootstrap, decommission, node removal and replacement now run against an agreed view of cluster membership. The database coordinates their ordering and progress, allowing operations such as adding multiple nodes concurrently. Consistent topology changes became mandatory in 2025.2.

This changes failure handling. Losing the metadata Raft quorum can block schema and topology changes. Ordinary reads and writes may continue if the necessary data replicas are reachable and the requested consistency level can be met. That is not a guarantee that a metadata-quorum failure leaves application traffic unaffected: the same failed nodes or network partition can also make data unavailable.

Gossip remains part of node-state dissemination. Raft takes responsibility for metadata that needs an agreed order. Cassandra's Transactional Cluster Metadata proposal addresses a related problem, so this is also an area where comparisons with an old Cassandra release can be misleading. Both projects have been changing cluster management.

Raft for user data is a separate step

Using Raft for schema does not make ordinary table operations strongly consistent. Those operations still use the familiar consistency levels, such as ONE, QUORUM and LOCAL_QUORUM. Conditional writes use Lightweight Transactions, backed by Paxos.

The experimental Strongly Consistent Tables feature in 2026.2 puts Raft into the user-data path, with a Raft group per tablet. Tablets provide a natural boundary: the database already knows which replicas hold each unit of data, and different groups can coordinate independently.

The experimental guarantee concerns requests to the same partition. Multi-key transactions remain a longer-term direction.

Raft-backed writes require agreement within their replication group, so replica placement, network latency and quorum availability directly affect them. Metadata Raft and per-tablet Raft have separate jobs and quorum requirements.

Alternator gives ScyllaDB a second API

ScyllaDB's Cassandra compatibility is no longer its only application-facing interface. Alternator implements a DynamoDB-compatible API directly on ScyllaDB storage. A DynamoDB hash key maps to a partition key, and an optional sort key maps to a clustering key.

This makes ScyllaDB relevant to a different migration discussion. A team using DynamoDB may be interested in preserving its application API while changing where the database runs and how it is operated.

Compatibility needs checking beyond PutItem and GetItem. Applications also depend on indexes, conditional operations, streams and the behaviour of their SDKs. Matching the basic request format is only part of a migration.

In 2026.2, Alternator Streams became generally available. They expose ordered changes at the item level, supporting applications that react to updates. That should not be read as a global ordering guarantee across the table or an end-to-end exactly-once guarantee for consumers. The same release added a vector-search extension to the DynamoDB-compatible API, with vector search available through ScyllaDB Cloud.

Alternator tables can use tablets too, sharing the placement and migration machinery with CQL tables.

Repair is moving into the database

Replicas still need repair. Tablets and Raft-managed topology do not remove that requirement for ordinary replicated tables.

Alongside repair orchestrated by ScyllaDB Manager, ScyllaDB provides built-in automatic repair for tablet tables. Incremental repair is also tied to the tablet architecture.

The database can schedule repair around the units it already tracks for placement. Check which tables use tablets, their repair settings, and how you will monitor completion and failures.

Logstor explores a different storage engine

Logstor is an experimental key-value backend that appends records to log segments and keeps an in-memory index of their locations. Compaction relocates live records to reclaim old segment space. This is a different storage path from memtables and SSTables, with index memory usage part of the cost.

The development snapshot examined here, also covered by DeepWiki, requires an experimental feature flag; this is not a 2026.2 availability claim. I would follow it for workloads dominated by replacing values and looking them up by key. Whether it is a useful alternative depends on its supported operations and measured behaviour.

The data-model constraints remain familiar

CQL, partition keys, clustering keys, replication factors, memtables and SSTables remain central to ScyllaDB. Much of the practical knowledge from operating Cassandra still applies.

You still need to choose partition keys around access patterns, control partition size, understand tombstones and compaction, and select consistency levels deliberately. A busy partition can still overload a shard. A large deletion workload can still create read amplification. Adding nodes does not automatically fix either problem.

That is why I would keep Cassandra data-model experience close during a migration, while revisiting operational assumptions about placement, drivers, topology changes and repair. Familiar CQL can make a system look more familiar than it actually is.

The licence belongs in the evaluation

Current ScyllaDB database releases are source-available, rather than AGPL open source. ScyllaDB OSS 6.2.x was the final AGPL database release. With 2025.1, the company combined its Open Source and Enterprise streams into one product line.

The source-available FAQ describes free-use limits of 10 TB of total provisioned disk capacity and 50 vCPUs per organisation, across clusters. The disk limit concerns capacity, not just the amount of application data stored. These caps are not the whole eligibility test: the current licence agreement also sets conditions on eligibility and use.

Older AGPL releases retain their licences. Seastar, drivers and the Kubernetes operator have their own licences. For a new deployment using current database features, however, the source-available terms need to be part of the decision from the start.

What I would compare today

If I had to pick the change that most affects how I think about ScyllaDB, it would be tablets. Shard-per-core determines how work is divided within a server. Tablets give ScyllaDB finer control over placement across the cluster, and a unit on which to build migration, balancing, repair and now experimental data consensus.

A Cassandra-to-ScyllaDB evaluation should therefore go beyond steady-state throughput. I would test adding and replacing nodes under load, observe latency while tablets move, verify client routing, and check the repair procedure. I would also separate established functionality from experiments before comparing feature lists.

The execution engine still matters. But a cluster that serves queries quickly and a cluster that can redistribute data predictably solve different parts of the operational problem. Tablets and Raft make the second part a much larger part of the ScyllaDB discussion.

These are the differences I would include in a Cassandra - ScyllaDB comparison today:

Reviewed by: Krzysztof Ciesielski Grzegorz Kocur