Cassandra vs ScyllaDB in 2026, in depth: where the two CQL databases diverged, and how to check whether your application can still move

What is still shared

Both databases still speak CQL over the same native protocol, so the DataStax-lineage drivers and ScyllaDB's shard-aware forks connect to either. Both partition data by a hashed partition key, replicate with a per-keyspace replication factor, and let each query choose a consistency level such as LOCAL_QUORUM. Both store data in memtables flushed to immutable SSTables merged by compaction. Both offer lightweight transactions, the IF NOT EXISTS and IF col = value conditions, implemented with Paxos on a single partition.

If your application uses plain tables, prepared statements, batches within a partition and LWTs, it can still move between them with driver configuration changes and a data migration. The trouble starts with the features each side added recently.

The release picture in October 2026

Two things stand out. Cassandra's biggest changes are in a release that was still pre-GA when this was written, so planning around them means planning around a date you do not control. And ScyllaDB's headline consistency feature is labelled experimental, which in practice means not for production data you cannot afford to lose.

Divergence 1: two different answers to strong consistency

Paxos LWTs give you linearizable compare-and-set on one partition, at the cost of several round trips and poor behaviour under contention. Both projects decided that was not enough, and chose opposite designs.

Cassandra 6.0 adds Accord, a leaderless consensus protocol that provides ACID transactions with strict serializability across multiple partitions, on tables you mark as transactional. Leaderless means any coordinator can drive a transaction, without a per-range leader, which suits Cassandra's existing masterless model. The point is multi-partition atomicity: move a balance between two accounts that hash to different nodes, in one transaction.

ScyllaDB's experimental feature instead makes a whole keyspace strongly consistent by replicating it with Raft, the leader-based protocol it already uses for metadata. ScyllaDB describes performance as close to its eventually consistent mode. That gives every read and write in the keyspace linearizable semantics without application-level conditions, but it is a replication model, not a multi-statement transaction language.

The practical result: an application written around Accord transactions will not run on ScyllaDB, and one that relies on ScyllaDB's consistent keyspaces gets nothing equivalent on Cassandra 5.0. If you need cross-partition atomicity today, on GA software, you still design around single-partition LWTs as described in when to use LWTs, or keep that data in a relational store.

Divergence 2: metadata and data distribution

Cassandra historically spread schema and ring membership by gossip, which converges eventually and has produced schema disagreements and racing topology changes. Cassandra 6.0's Transactional Cluster Metadata replaces that with a Cluster Metadata Service holding an ordered log of metadata changes, so every node applies schema and topology changes in the same order. Data still lives on token ranges assigned through vnodes, explained in Cassandra vnodes.

ScyllaDB moved schema and topology onto Raft and then changed data distribution itself. With tablets, each table is split into tablets that are assigned to nodes and moved independently, so adding a node rebalances by migrating tablets rather than by recomputing token ownership and streaming whole ranges. Tablets have been the default for new keyspaces since 2025.1; migrating existing vnode keyspaces to tablets was still experimental in 2026.3.

For operators this changes routine work. Scaling a ScyllaDB tablet cluster is closer to an online rebalance, while Cassandra keeps the familiar bootstrap, streaming and cleanup sequence with safer metadata underneath. Runbooks, monitoring and capacity plans do not transfer between the two.

Divergence 3: indexing and search

Cassandra 5.0's storage-attached indexes build per-SSTable index structures alongside the data, created with CREATE INDEX ... USING 'sai', and they underpin Cassandra's vector search. ScyllaDB does not implement SAI. Its secondary indexes are built on materialized views, global indexes stored as separate tables, with different cost: a write updates the view, and a query reads the index and then the base table.

On search, ScyllaDB went further: vector search is offered in ScyllaDB Cloud, and 2026.3 made full-text search with BM25 relevance scoring generally available, queried from CQL with its own index type and function. Because the syntax differs from Cassandra's, any query that uses SAI, vector search or full-text search must be rewritten when moving in either direction, and its performance re-measured.

Divergence 4: licensing and operations

Cassandra is an Apache Software Foundation project under the Apache License 2.0. ScyllaDB moved to a source-available license with 2025.1; the last AGPL open-source release was 6.2. The source-available build is free up to 50 vCPUs and 10 TB of total storage per organisation, across all clusters. Beyond that you need a commercial agreement. Count vCPUs as hyperthreads across every environment, including staging and disaster recovery, because that is how a cluster that started free crosses the line.

Operations differ too. Cassandra 6.0 brings repair orchestration into the database, where operators previously relied on external tools such as Reaper; Cassandra repair in 2026 covers the options. ScyllaDB pairs the database with ScyllaDB Manager for repair and backup, and 2026.3 added cluster-wide restore from object storage for tablet tables.

Audit your schema before you compare benchmarks

Most migration surprises are in the schema, not the throughput. The script below reads system_schema, which both databases expose, and lists features to check by hand: custom indexes such as SAI, counters, materialized views, user-defined functions and aggregates, triggers, and compaction classes that exist on only one side (Cassandra's unified compaction strategy, ScyllaDB's incremental compaction strategy).

"""Flag schema features that will not move cleanly between Cassandra and ScyllaDB."""
from cassandra.cluster import Cluster

SYSTEM = {"system", "system_auth", "system_schema", "system_distributed",
          "system_traces", "system_virtual_schema", "system_views"}

def audit(contact_points):
    s = Cluster(contact_points).connect()
    findings = []

    for r in s.execute("SELECT keyspace_name, table_name, compaction "
                       "FROM system_schema.tables"):
        if r.keyspace_name in SYSTEM:
            continue
        cls = r.compaction.get("class", "")
        if "Unified" in cls or "Incremental" in cls:
            findings.append((r.keyspace_name, r.table_name, "compaction " + cls))

    for r in s.execute("SELECT keyspace_name, table_name, index_name, kind, options "
                       "FROM system_schema.indexes"):
        if r.kind == "CUSTOM":
            findings.append((r.keyspace_name, r.table_name,
                             "custom index %s: %s" % (r.index_name, r.options.get("class_name"))))

    for r in s.execute("SELECT keyspace_name, table_name, column_name, type "
                       "FROM system_schema.columns"):
        if r.type == "counter":
            findings.append((r.keyspace_name, r.table_name, "counter column " + r.column_name))

    for name in ("views", "functions", "aggregates", "triggers"):
        try:
            rows = s.execute("SELECT * FROM system_schema." + name)
        except Exception as e:          # table absent on this server: note it, carry on
            findings.append(("-", "-", "cannot read system_schema.%s: %s" % (name, e)))
            continue
        for r in rows:
            if r.keyspace_name not in SYSTEM:
                key = "/".join(str(v) for v in list(r)[1:3])
                findings.append((r.keyspace_name, "-", name[:-1] + " " + key))
    return findings

for ks, table, issue in audit(["10.0.0.11"]):
    print(f"{ks}.{table}: {issue}")

Treat each line of output as a question, not a verdict. Counters work on both, but counters on tablets only arrived in ScyllaDB 2026.1. Java UDFs do not port, because ScyllaDB's UDFs are not written in Java. Materialized views exist on both, but Cassandra still flags them as experimental. Driver-side checks matter as well: search the code for SERIAL consistency, USING TIMESTAMP, and any per-node assumptions such as token-aware routing policies.

Worked example: a 12-node cluster deciding in 2026

Assume a team runs Cassandra 4.1 on 12 nodes with 16 vCPUs each (192 vCPUs) and 4 TB per node, 48 TB raw at replication factor 3. The workload is user events and account balances. The balance updates currently use LWTs and occasionally time out under contention.

The audit finds two SAI-equivalent needs (the team wants to query events by type without a denormalised table), counters for daily totals, and no UDFs or triggers.

Option A, Cassandra 5.0 now, 6.0 later. Upgrade 4.1 to 5.0 and replace the denormalised table with SAI. Keep balances on LWT. Revisit Accord for balances once 6.0 is GA and has run in staging for a quarter. License cost zero; operational change small.

Option B, ScyllaDB 2026.3. At 192 vCPUs and 48 TB the cluster is far above the free tier, so this is a commercial decision before it is a technical one. ScyllaDB's per-core efficiency may cut the node count; measure it, because a 3x reduction to 64 vCPUs would still exceed 50. SAI queries become secondary-index or denormalised queries. Balances stay on LWT unless the team accepts an experimental consistent keyspace, which it should not for money.

With these numbers Option A wins on risk, while Option B is worth a benchmark only if the projected node reduction pays for the license. The reasoning, not the answer, is what transfers: list required features, mark which are GA on each side today, and price the license at your real vCPU count. When to pick Cassandra covers the earlier question of whether either fits.

Failure modes in evaluations and migrations

• Unequal benchmarks. Comparing a tuned cluster with a default one, or different instance types, measures the operators, not the databases. Use the same hardware, data size, consistency level and a shard-aware driver for ScyllaDB.
• Building on experimental or pre-GA features. Accord before 6.0 GA and ScyllaDB's consistent keyspaces are both reasons to wait, not to migrate.
• License drift. A ScyllaDB cluster under the free tier grows past 50 vCPUs through ordinary scaling; track the total across all clusters.
• Dual-write drift. Migrating by writing to both clusters without verification leaves silent differences; compare checksums by token range before cutover.
• Forgotten compaction semantics. Strategy names and options differ, and a table moved without retuning can amplify writes, as compaction strategies explains.

Trade-offs

What to do next

1. Run the schema audit against every keyspace and list each finding with its owner.
2. Mark each feature you depend on as GA, experimental or pre-GA on both sides, using the current release notes rather than this table.
3. Count total vCPUs and storage across all clusters if ScyllaDB is an option, and price the license before benchmarking.
4. Benchmark on identical hardware with your real data model and consistency levels, including a node replacement and a scale-out.
5. Keep cross-partition logic on LWT or a relational store until Accord is GA and proven in your staging environment.
6. If you migrate, verify data by token-range checksums before cutting reads over.