Wide-column databases in 2026: revisit Apache Cassandra, ScyllaDB and YugabyteDB YCQL before you design another partition key

Most teams meet a wide-column database through one table that grew too fast for everything else: an event log per user, a delivery history, a feed or a “last 90 days of activity” screen. The relational database coped for a year, then the table crossed a few billion rows, writes arrived in bursts, and someone said “let us move this to Cassandra”. The move worked. Three years later the team has a cluster nobody wants to touch, a repair job that has not finished in months, one partition that times out every month end, and a Cassandra version the project no longer maintains.

That is the moment this post is written for. Wide-column databases are very good at one shape of work: high write rates, reads by a known key, data spread across many machines and data centres, and no single point of failure. They are unforgiving when the data model does not match the questions the application asks. Much of the pain blamed on “Cassandra” is really a partition key designed for the first screen of the app and never revisited.

This post revisits three engines that speak the Cassandra Query Language (CQL) in 2026: Apache Cassandra (5.0 line, with a look at what 6.0 brings), ScyllaDB (the C++ rewrite, now under a source-available licence) and YugabyteDB YCQL (the Cassandra-flavoured API of a Raft-based distributed database). We also mention Apache HBase and the managed CQL services. The aim is not to crown the fastest engine. It is to understand how each one stores and replicates data, what the licence allows, what day two looks like, and how to model tables so that the engine you choose does not punish you later.

A few pieces of news set the scene. Apache Cassandra 5.0.9 came out on 7 August 2026, together with 4.1.12, 4.0.21 and the second alpha of Cassandra 6.0. The 5.0.8 release, earlier in 2026, brought the built-in automatic repair scheduler from the 6.0 work back into 5.0, behind a switch that is off by default. ScyllaDB changed its licence again on 12 April 2026: the free source-available licence is now limited to organisations that have not been paying ScyllaDB customers in the previous twelve months, on top of the earlier 10 TB and 50 vCPU limit. ScyllaDB 2026.3, released in September, made the move from vnodes to tablets generally available and added full-text search and large data guardrails. YugabyteDB 2026.1 made OIDC token login for YCQL generally available, and the next long term support line, 2026.2, is planned for the end of 2026.

This post stays with wide-column and CQL workloads. If your real need is SQL with joins and transactions across regions, read distributed SQL in 2026, which covers YugabyteDB’s PostgreSQL-compatible YSQL side. Sensor data with time-bucketed queries may fit better in a time-series database, and dashboards over billions of rows belong in real-time OLAP. Document workloads are covered in MongoDB alternatives in 2026. If you only need a very fast key-value cache, start with Redis, Valkey and Dragonfly. Streaming changes out of a CQL cluster is discussed in change data capture in 2026, and running stateful databases on Kubernetes volumes in Kubernetes storage in 2026.

A scenario to keep us honest

We will use one invented company through the post. Sukhna Alerts is an invented example, not a real business. It is a Chandigarh company that sends transactional messages for banks, NBFCs and insurers in north India: OTPs, debit and credit alerts, EMI reminders, policy renewal notices and statements. Messages go out over SMS, WhatsApp and email through several gateway partners. The company has 60 people, of whom 28 are engineers. A platform team of four, led by Harpreet, runs the databases.

What they run today:

  • A six node Apache Cassandra 3.11 cluster on virtual machines in one cloud region, replication factor 3, each node with 8 vCPUs, 32 GB of memory and a 2 TB SSD. About 6.5 TB of data on disk across the cluster, including the three copies.
  • Three main tables: a message table keyed by message id, a delivery events table where every gateway callback is appended, and a customer inbox table that powers the “all messages sent to me” screen inside two banks’ mobile apps.
  • A secondary index on delivery status, added during an incident so support could find “all failed messages for a bank today”.
  • Writes of about 8,000 per second on a normal day and close to 30,000 per second at peaks: salary days, the first week of the month for EMI reminders, and festival offer campaigns.
  • Repairs run by hand with nodetool when someone remembers. The last full repair was more than four months ago.

What triggered the review: the 3.11 line is no longer maintained, and a bank’s security team asked which supported version they run. In the same month, the inbox screen for one large bank timed out during a campaign: the inbox partition was keyed by bank and day, so every message for that bank on that day landed in one partition of several gigabytes. Support also found that a few messages deleted on request were visible again after a node replacement.

Harpreet’s questions: should we upgrade Cassandra, move to ScyllaDB, or move to YugabyteDB YCQL; what will each cost us in licences and people; can the four of us run it for five years; and how do we stop the data model from hurting us again?

The short version

  • Model by query first, engine second. All three engines punish large partitions, unbounded rows per key and queries that do not name the partition. Fix the partition key and the clustering order before you migrate anything.
  • Apache Cassandra 5.0 is the safe, fully open source default in 2026. It brings Storage Attached Indexes (SAI), vector search, the Unified Compaction Strategy, trie memtables and trie-indexed SSTables, Java 17 and dynamic data masking. Several of the best new pieces are opt-in, and the upgrade from 4.x has a deliberate three step storage compatibility process. Cassandra 6.0 with Accord transactions is still in alpha.
  • ScyllaDB offers the same data model and CQL drivers with a shard-per-core C++ engine, tablets for faster scaling, native backup to object storage and strong vendor tooling. Since 2025 it is source-available, not open source, and since April 2026 the free licence is limited to organisations that have never been customers in the last twelve months and stay under 10 TB of storage and 50 vCPUs in total.
  • YugabyteDB YCQL looks like CQL but behaves like a strongly consistent database: Raft replication, single-row linearisability, consistent secondary indexes and multi-row transactions. It drops tunable consistency and several Cassandra features, and its own documentation says the compatibility is not meant for lift-and-shift.
  • For Sukhna Alerts, our plan is to stay on Apache Cassandra, upgrade 3.11 to 4.1 and then to 5.0, redesign the inbox and events tables around bucketed partitions and time windows, replace the old secondary index with SAI, and put repair and backups on a schedule. ScyllaDB stays on the list if the company later wants vendor support and is ready to buy a licence.

Where things stand on 1 November 2026

Apache Cassandra

Apache Cassandra is an Apache Software Foundation project under the Apache 2.0 licence. The project maintains three release lines. The download page lists 5.0.9 as the latest GA release (7 August 2026), maintained until the 8.0 release; 4.1.12 as the previous stable line, maintained until 7.0; and 4.0.21 as the older stable line, maintained until 6.0. Everything older, including 3.11 and 3.0, is marked unmaintained, with CVE fixes applied only case by case.

Cassandra 5.0.0 was released on 5 September 2024 with SAI, trie memtables, trie-indexed SSTables (the “bti” format), the Unified Compaction Strategy (UCS), a vector type with approximate nearest neighbour search, dynamic data masking and extended maximum TTL dates. Java 8 was removed; the minimum is Java 11, and Java 17 became fully supported in 5.0.5.

Cassandra 6.0 is available only as alpha releases (6.0-alpha2 on 7 August 2026) with no announced GA date. Its headline features are Accord, a consensus protocol that brings general purpose ACID transactions across partitions, Transactional Cluster Metadata (TCM), which replaces gossip for schema and token ownership changes, and the automated repair scheduler.

The project also publishes its own drivers (the Java driver is at 4.19.4, 14 October 2026). DataStax, the largest commercial Cassandra company for years, became part of IBM when IBM completed the acquisition on 28 May 2025.

ScyllaDB

ScyllaDB is developed by ScyllaDB Ltd. It is a reimplementation of Cassandra’s data model and protocol in C++ on the Seastar framework, with a DynamoDB-compatible API called Alternator on the side. The company announced on 18 December 2024 that it would merge its open source and enterprise editions into one source-available release stream. ScyllaDB Open Source 6.2 was the final AGPL release, and ScyllaDB 2025.1 (April 2025) was the first source-available release.

Releases now come as yearly long term support (LTS) versions and short term support (STS) feature versions two to four times a year. The vendor supports the two most recent LTS releases and the two most recent feature releases. On 1 November 2026 the current versions are 2026.1.15 (LTS, 28 October 2026), 2026.3.4 (STS, 29 October 2026), 2026.2.10 (STS, 30 October 2026) and 2025.1.16 (the previous LTS, 2 October 2026).

ScyllaDB 2026.1 (March 2026) completed counter support on tablets, closing the last gap with vnodes. ScyllaDB 2026.3 (September 2026) made vnodes to tablets migration generally available and added a full-text search index, large data guardrails, cluster-wide restore from object storage and a preview of keyspaces stored on S3. Vector search exists but, per the vendor’s documentation, is a ScyllaDB Cloud feature.

Supporting tools keep their own licences: Scylla Manager (backups and repair scheduling) is AGPL 3.0 and at 3.13.0, the Scylla Operator for Kubernetes is Apache 2.0 and at 1.23.0, and the drivers and Seastar keep their existing licences.

YugabyteDB YCQL

YugabyteDB is a distributed database from Yugabyte Inc with two query APIs on one storage layer: YSQL, which reuses the PostgreSQL query layer, and YCQL, which has its roots in CQL. The core database is Apache 2.0; YugabyteDB Anywhere, the self-managed control plane, is under a Polyform Free Trial licence for 32 days of evaluation and needs a commercial licence for production.

The release table lists v2025.2 as the current LTS line (released 11 December 2025, latest patch 2025.2.8.0 on 23 October 2026) and v2026.1 as the current STS line (released 29 June 2026, latest patch 2026.1.2.0 on 22 September 2026). The next LTS, v2026.2, is planned for the end of 2026. In 2026.1, OIDC token login for YCQL became generally available, so YCQL users can sign in with a JWT from an identity provider as the password.

The two APIs are isolated. Data written through YCQL cannot be read through YSQL, so you choose the API before you design the schema.

Around them

  • Apache HBase, modelled after Google Bigtable and built on HDFS, released 3.0.0 on 5 August 2026 and 2.6.7 on 1 October 2026. It fits well inside a Hadoop estate but does not speak CQL, so we keep it as context.
  • Managed CQL services include Amazon Keyspaces, DataStax Astra DB, Azure Managed Instance for Apache Cassandra, ScyllaDB Cloud and YugabyteDB Aeon. Each has its own limits on CQL features and consistency; read the compatibility page before assuming your schema moves unchanged.
  • Cassandra community tooling is active: Cassandra Reaper 5.1.0 for repairs (26 October 2026), Cassandra Medusa 0.31.1 for backups (30 October 2026) and the K8ssandra operator 1.33.0 for Kubernetes, all Apache 2.0.

The first questions to ask

Before comparing engines, write down answers to these:

  1. What are the five most important queries, word for word? “Messages for customer X in the last 30 days, newest first” is a query. “Search messages” is not.
  2. What is the largest partition you will create, in rows and in bytes, after five years? If you cannot estimate it, your partition key is probably unbounded.
  3. Do you need tunable consistency, or strong consistency everywhere? Cassandra and ScyllaDB let each query choose; YCQL is always strongly consistent for writes.
  4. Do you need multi-row or multi-partition transactions today? If yes, be honest that the classic wide-column model does not give them, and look at YCQL, Cassandra 6.0 when it is GA, or a SQL database.
  5. How is data deleted? TTL, explicit deletes, or never? Deletes create tombstones, and tombstones decide your repair and compaction plan.
  6. How many data centres or regions, and must each one accept writes?
  7. What is your total storage and vCPU footprint across every cluster, including test and staging? This matters for the ScyllaDB licence.
  8. Who repairs, backs up and upgrades the cluster, and how many hours a month do they have?
  9. What does the business need from a vendor: a support contract, a managed service, or neither?

How each one works

Apache Cassandra: Dynamo distribution, Bigtable storage, on the JVM

Cassandra combines a Dynamo-style cluster with a Bigtable-style storage engine. Every node is equal. The partition key is hashed onto a token ring and each node owns several token ranges (num_tokens is 16 by default). A keyspace sets the replication factor per data centre, and each request goes to a coordinator that forwards it to the replicas.

Writes go to a commit log and an in-memory memtable, and are flushed to immutable SSTables. Updates and deletes are new writes with newer timestamps; a delete writes a tombstone. Reads merge the memtable and the SSTables that might hold the partition, using bloom filters and indexes to skip files. Compaction merges SSTables in the background, drops overwritten data and, after gc_grace_seconds, drops tombstones.

Consistency is chosen per request. With replication factor 3, reading and writing at LOCAL_QUORUM (two of three local replicas) gives read-your-writes within a data centre. Replicas drift after dropped writes and outages; hinted handoff and read repair help, but only anti-entropy repair is complete, which is why repair is not optional. Lightweight transactions (IF NOT EXISTS, IF column = value) give compare-and-set on one partition using Paxos, at the cost of extra round trips.

What Cassandra 5.0 changed for everyday modelling:

  • Storage Attached Indexes. SAI indexes are attached to each SSTable and memtable instead of living in a hidden table like the old secondary indexes. They support equality and range queries and several indexed columns in one query. They are still secondary indexes: a query that does not name the partition fans out to many nodes, so combine them with a partition key restriction or keep them for low volume queries.
  • Vector search. A vector column type, similarity functions and ORDER BY ANN OF queries on an SAI index, using the jvector library.
  • Unified Compaction Strategy. One configurable strategy that can behave like size-tiered or levelled compaction depending on a scaling parameter, designed for lower space overhead and more parallel compaction.
  • Trie memtables and trie-indexed SSTables. New memtable and SSTable index formats with better memory use and faster lookups, especially for partitions with many rows.

The important detail is that the default cassandra.yaml in 5.0.9 still uses the skiplist memtable, the older “big” SSTable format and size-tiered compaction. A second file, cassandra_latest.yaml, switches on the trie memtable, the bti format and UCS, and the project recommends it for production only after careful evaluation. So “we upgraded to 5.0” does not mean “we use the 5.0 storage engine”.

A small example of the 5.0 style, for a table that keeps the latest delivery status per message and lets support filter within one bank’s day:

CREATE INDEX msg_status_sai ON alerts.message_by_bank_day (status) USING 'sai';

SELECT message_id, status, updated_at
FROM alerts.message_by_bank_day
WHERE bank_id = 'BANK07' AND day = '2026-10-31' AND bucket = 3
  AND status = 'FAILED';

The query names the full partition key, so the index narrows rows inside a known partition instead of scanning the cluster.

ScyllaDB: the same model, a different engine

ScyllaDB keeps Cassandra’s data model, CQL, consistency levels and driver protocol, and publishes its own shard-aware drivers. Inside, it is very different. It is written in C++ on Seastar and splits each node into shards, one per CPU core, each owning a slice of the data and memory and talking to other shards by message passing instead of locks. It keeps its own cache and schedulers that balance user queries against compaction, streaming and repair. There is no JVM to tune.

Two newer pieces change operations:

  • Tablets. Instead of fixed token ranges per node (vnodes), tablet keyspaces split each table into tablets that the cluster moves and splits automatically, so adding or removing nodes is a background task. Existing vnode keyspaces can be migrated online since 2026.3.
  • Raft for metadata. Schema and topology changes use Raft, and strongly consistent tables (a Raft group per tablet) are experimental since 2026.2.

ScyllaDB also has features Cassandra does not, such as Alternator for DynamoDB applications, native backup to object storage and workload prioritisation. In the other direction, check every Cassandra feature you rely on against ScyllaDB’s documentation; the two have diverged over ten years.

YugabyteDB YCQL: CQL on top of Raft

YCQL accepts CQL syntax and Cassandra drivers (Yugabyte also publishes its own driver forks), but the storage underneath is DocDB, built on a modified RocksDB. Tables are split into tablets, each tablet is replicated with Raft, and every write is committed by a Raft majority.

That design changes the guarantees:

  • Single-row reads and writes are linearisable. Yugabyte describes YugabyteDB as a CP database, where Cassandra is AP.
  • Secondary indexes are strongly consistent, because they are maintained with distributed transactions, and YCQL supports unique indexes.
  • Multi-row ACID transactions exist (BEGIN TRANSACTION … END TRANSACTION).
  • Tunable write consistency is not allowed, because every write goes through Raft. Lightweight transactions are unnecessary for compare-and-set, and COUNTER behaves like an integer.
  • Writes without USING TIMESTAMP always overwrite older values, which differs from Cassandra’s “highest timestamp wins” rule.

It also gives up some Cassandra features. Yugabyte’s feature support page lists UPDATE and DELETE as single row only, no GROUP BY or PER PARTITION LIMIT, batches only through the driver API, and no materialised views, triggers, user defined functions or user defined aggregates. A JSONB column type is available. Its own FAQ says the API compatibility is meant to help developers start quickly, not to run existing Cassandra applications unchanged.

Data modelling by query

This is the section to read twice. Wide-column databases store rows grouped by partition key, sorted by clustering columns. The partition is the unit of distribution, of replication and, in practice, of pain.

Start from the screens and jobs

List every query with its filters and sort order. Then create one table per query pattern, and accept that the same data is written to more than one table. In a relational database this is denormalisation and feels wrong. In a wide-column database it is the normal way to buy fast reads. The application, or a stream processor, writes to all the tables that need the data.

Bound every partition

A partition should have a known upper size. Common ways to bound it:

  • Time buckets. Add a day, week or month to the partition key for event data: (customer_id, month) instead of customer_id.
  • Hash buckets. Add a small bucket number for keys that are naturally hot: (bank_id, day, bucket) where bucket is message_id hashed into, say, 16 values.
  • Retention. Use TTL so old data expires instead of being deleted row by row.

Know your largest partition and set a limit for it. Cassandra 5.0 added the offline sstablepartitions tool to find large partitions and a guardrail for partition size, and ScyllaDB 2026.3 added large data guardrails that warn or block. Use them; do not rely on memory.

Choose clustering order for the common read

If the screen shows newest first, cluster by time descending. A query for “the latest 50” then reads the beginning of the partition and stops.

For the Sukhna inbox, the old table was keyed by (bank_id, day). The new design is per customer and month, newest first:

CREATE TABLE alerts.inbox_by_customer (
    bank_id      text,
    customer_ref text,
    month        text,
    sent_at      timeuuid,
    message_id   uuid,
    channel      text,
    template_id  text,
    preview      text,
    PRIMARY KEY ((bank_id, customer_ref, month), sent_at)
) WITH CLUSTERING ORDER BY (sent_at DESC)
  AND default_time_to_live = 15552000;

The TTL is 180 days, which matches what the banks show in their apps. A customer receives a few hundred messages a month, so each partition stays small. Support queries by bank and day move to a separate table bucketed by hash.

Be careful with deletes

A delete writes a tombstone, kept for gc_grace_seconds (ten days by default) so that a replica that missed the delete learns about it during repair. If repair does not run within that window and compaction drops the tombstone, a replica that still holds the old value can bring it back. That is the problem Sukhna saw after a node replacement. The fix is a repair schedule that always completes within gc_grace_seconds, and a model that expires data with TTL instead of deleting rows one by one.

Use the right compaction for the shape of data

  • Append-only data with TTL, read by recent time: time window compaction (TWCS), so whole SSTables expire together.
  • Update-heavy data that is read often: levelled compaction, or UCS tuned towards levelled behaviour in Cassandra 5.0.
  • General purpose data: size-tiered compaction, or UCS after testing.

Know what changes on YCQL

On YCQL a strongly consistent secondary index can replace a second table for low volume lookups, at the cost of a distributed transaction on every write. But multi-row updates and deletes are not available, so models that rely on them need rework.

Consistency, transactions and multi-region

  • Cassandra offers tunable consistency per query, LWT for compare-and-set within one partition, and multi data centre replication with NetworkTopologyStrategy. LOCAL_QUORUM in each data centre is the usual setting. Cross-partition transactions arrive with Accord in 6.0, which is still alpha.
  • ScyllaDB offers the same consistency levels and LWT (implemented with Paxos), plus Raft for schema and topology. In 2026.3, LWT gained arithmetic updates, and strongly consistent tables are experimental.
  • YCQL commits every write through Raft and reads from the tablet leader by default; follower reads trade bounded staleness for latency. Across regions, writes pay a cross-region round trip unless leaders are placed near the writers.

For Sukhna, which runs in one region with three availability zones, Cassandra’s LOCAL_QUORUM on replication factor 3, with one replica per zone, is enough. The consent table, where a customer opts out of promotional messages, uses LWT for “insert only if absent” and is low volume.

Performance claims and how to read them

ScyllaDB publishes comparisons against Cassandra on its benchmarks page. The vendor’s summary says ScyllaDB has two to five times better throughput and lower latencies than Cassandra, finishes compaction 32 times faster, and that a ScyllaDB cluster can be ten times smaller and 2.5 times less expensive. A 2025 vendor talk compared Cassandra 5.0.2 and ScyllaDB 2024.2 on AWS i4i.4xlarge nodes with replication factor 3 and LOCAL_QUORUM. These are the vendor’s own runs. They are useful as a sign of where the C++ engine helps (CPU efficiency, tail latency under compaction, faster node operations), but they are not a forecast for your workload.

Cassandra results depend heavily on the Java version, heap, memtable and SSTable format and compaction strategy; a 5.0 cluster on the default yaml and one on cassandra_latest.yaml settings behave differently. YCQL pays for Raft and consistent indexes with extra work per write, so comparing it on raw write throughput misses its point. And most real incidents in this category come from data model problems, not engine speed: a faster engine with the same bad partition key gives you a faster incident. Run your own test with your partition sizes, read and write mix and consistency level, and measure p99 latency during a node restart and during repair, not only at steady state.

Licences and commercial models

  • Apache Cassandra is Apache 2.0, owned by the Apache Software Foundation. There is no usage limit, no field of use restriction and no vendor that can change the licence of future releases on its own. Commercial support and managed services come from several companies, including IBM (DataStax), AWS (Keyspaces, a compatible service, not Cassandra itself), Azure and independent consultancies.
  • ScyllaDB is source-available under the ScyllaDB Software License Agreement, version 1.1 of 12 April 2026. You can read and modify the code, but free use is limited to “Never Customers”: organisations (with their affiliates) that have had no paid relationship with ScyllaDB in the previous twelve months. Existing customers may use the free licence only for non-production CI, testing and QA. Free use is capped at 10 TB of total storage and 50 vCPUs across all clusters, may not be offered as a database service, and may not be used to compete with ScyllaDB. Modified versions are assigned to the licensor, and the licensor may audit. Anything beyond that needs a commercial licence or ScyllaDB Cloud. ScyllaDB Open Source 6.2 remains available under AGPL 3.0, but it receives no new releases.
  • YugabyteDB core is Apache 2.0, including YCQL. YugabyteDB Anywhere, the management plane many enterprises use, is commercial after a 32 day trial, and YugabyteDB Aeon is the managed service.

For Sukhna the ScyllaDB numbers matter. Six nodes of 8 vCPUs are 48 vCPUs, under the 50 vCPU limit, but six 2 TB disks are 12 TB of storage, over the 10 TB limit, before counting a staging cluster. The licence counts available storage, not data stored. So Sukhna would need a commercial agreement for production ScyllaDB, and once it signs one, the free licence no longer applies anywhere in the company, including small side projects. That is not a reason to avoid ScyllaDB. It is a reason to budget for it honestly.

Operations and day two

Repair

  • Cassandra. Run repair on every table more often than gc_grace_seconds. nodetool repair runs incremental repair unless you ask for a full one, and full repair is still needed from time to time. Cassandra Reaper schedules and splits repairs. From 5.0.8, Cassandra also includes the CEP-37 automatic repair scheduler, but it must be enabled with a JVM property on every node before start, the property cannot be turned off again once used, and scheduling is then configured in cassandra.yaml or JMX. Plan it as a deliberate change, not a flag you try on one node.
  • ScyllaDB. Scylla Manager schedules row-level repair, and on tablet keyspaces the cluster-level repair API is used. Note that the 2026.3.4 patch fixed a case where a full incremental repair with repair-based tombstone garbage collection could purge a tombstone too early. Keep up with patch releases.
  • YCQL. Raft keeps replicas in sync, so there is no anti-entropy repair job to schedule. You still watch replication lag, under-replicated tablets and leader balance.

Compaction and disk headroom

Cassandra and ScyllaDB both need free disk for compaction. Size-tiered compaction needs the most headroom; levelled compaction and UCS need less, but never run disks close to full. Watch pending compactions, SSTables read per query and tombstones scanned per read. Cassandra’s auto_snapshot (on by default) keeps a snapshot when a table is dropped or truncated, and ScyllaDB 2026.3 now expires such snapshots after ten days by default; in Cassandra, clean them up deliberately.

Upgrades

  • Cassandra 3.11 to 5.0 is best done in two hops: 3.11 to 4.1, upgrade SSTables, then 4.1 to 5.0. Check removed features first: Java 8 is gone, DateTieredCompactionStrategy is removed (switch tables to TWCS before upgrading), Hadoop integration is removed, and two old date functions were removed. Upgrade drivers to versions that support protocol v4 or later.
  • The 5.0 storage step. After all nodes run 5.0, the cluster still writes 4.x compatible files because storage_compatibility_mode defaults to CASSANDRA_4. That keeps a rollback path. When you are confident, do one rolling restart with UPGRADING and another with NONE. Only then can TTLs expire beyond 2038 and new storage features be used. Do not turn on bti, the trie memtable or UCS in the same change window as the binary upgrade.
  • ScyllaDB supports upgrades from the previous LTS or feature releases (for example, 2026.3 from 2026.1 or 2026.2), with patch upgrades in between. Moving from the final AGPL release 6.2 to 2025.1 or later means accepting the source-available licence.
  • YugabyteDB does rolling upgrades, and its release notes list blocked paths; for example, clusters on 2025.2.6.0 must go to 2026.1.2.0 or later.

Backups and restore

  • Cassandra. nodetool snapshot gives hard-linked SSTable copies per node; incremental backups can add flushed SSTables. Medusa automates snapshot backups to S3-compatible storage, and restores either in place or to a new cluster. Back up the schema separately, and test a restore to a different cluster at least once a quarter.
  • ScyllaDB. Scylla Manager backs up to S3, GCS, Azure and, since 2026.3, OCI object storage, and tablet keyspaces can be restored cluster-wide through a REST API (Manager support for that is promised later).
  • YugabyteDB. Distributed snapshots and backups to object storage, made easier by the commercial YugabyteDB Anywhere.

Cloud costs

Wide-column clusters cost money in compute for every replica, disk for replicas plus compaction headroom, and network. With replication factor 3 across three zones, every write crosses zones twice, and repair and streaming add more, so measure inter-zone traffic before you migrate. Managed services charge per request, per capacity unit or per node; do not compare a self-managed bill without your engineers’ time against a managed bill that includes it.

Monitoring

Track per-table p99 latency, pending compactions, dropped messages, hints, tombstones per read, partition sizes, disk usage and, for Cassandra, garbage collection pauses. ScyllaDB ships a Prometheus and Grafana monitoring stack; Cassandra exposes metrics over JMX and virtual tables. See infrastructure monitoring in 2026 for the wider monitoring choice.

Side by side

  • Licence. Cassandra is Apache 2.0 with no usage limits. ScyllaDB is source-available with a free tier for never-customers up to 10 TB and 50 vCPUs; the last AGPL release is 6.2. YugabyteDB core is Apache 2.0; its management plane is commercial.
  • Consistency. Cassandra and ScyllaDB are tunable per query, with LWT for compare-and-set. YCQL is strongly consistent by design, with Raft for every write.
  • Transactions. Cassandra has single-partition LWT today, and Accord in 6.0 alpha. ScyllaDB has LWT and experimental strongly consistent tables. YCQL has multi-row ACID transactions now.
  • Secondary indexes. Cassandra 5.0 has SAI. ScyllaDB has global and local secondary indexes plus full-text and Cloud vector indexes. YCQL has strongly consistent, unique and covering indexes.
  • CQL coverage. ScyllaDB is closest to Cassandra but has diverged in places. YCQL is based on CQL 3.4 and leaves out materialised views, UDFs, UDAs, triggers, GROUP BY and multi-row updates.
  • Scaling. Cassandra uses vnodes and streaming when nodes join or leave; Transactional Cluster Metadata in 6.0 makes range movements safer. ScyllaDB tablets move and split data automatically. YugabyteDB tablets split and rebalance automatically.
  • Repair. Cassandra needs scheduled repair (Reaper, or built-in auto repair from 5.0.8 if enabled). ScyllaDB uses Scylla Manager and cluster repair. YCQL relies on Raft and needs no anti-entropy repair job.
  • Runtime. Cassandra runs on the JVM (Java 11 or 17 for 5.0). ScyllaDB and YugabyteDB are native C++.
  • Operations effort. Cassandra has the largest community and most third-party tools; ScyllaDB has strong tools from one vendor; YugabyteDB is easiest with its commercial control plane.
  • Performance. ScyllaDB’s own benchmarks show large gains over Cassandra; treat them as the vendor’s runs. Test with your data model and consistency level.

A worked plan for Chandigarh

Here is how we would take Sukhna Alerts from a Cassandra 3.11 cluster with a hot partition to a supported, boring cluster in about four months.

Month 1: model and measure.

  • Export the schema and run nodetool tablestats and tablehistograms on every node to find partition size percentiles and the largest partitions.
  • Write the five most important queries on one page with the owners’ names.
  • Redesign three tables: inbox by (bank_id, customer_ref, month) with TTL of 180 days; delivery events by (message_id) with TTL and TWCS; support lookups by (bank_id, day, bucket) with 16 hash buckets.
  • Plan to drop the old status index and use SAI on the bucketed support table after the 5.0 upgrade.
  • Run a full repair on every keyspace, table by table, during low traffic, to bring replicas in sync before anything else.

Month 2: upgrade to 4.1.

  • Upgrade the drivers first, and test against a staging cluster on 4.1.
  • Do a rolling upgrade from 3.11 to 4.1, one node at a time, with nodetool drain before each stop. After all nodes run 4.1, run upgradesstables.
  • Install Cassandra Reaper and schedule incremental repair weekly per keyspace, with a full repair monthly, all within the ten day gc_grace window for tables with deletes.
  • Install Medusa and back up to object storage in the same region nightly, with schema exports. Restore once to a separate test cluster.

Month 3: upgrade to 5.0 and switch tables.

  • Rolling upgrade from 4.1 to 5.0.9 on Java 17. Keep storage_compatibility_mode at CASSANDRA_4 for two weeks.
  • Create the new tables, dual-write from the application, and backfill the last 180 days with a batch job that reads the old table by token range.
  • Switch the bank apps’ inbox reads to the new table, one bank at a time. Remove the old index.
  • Rolling restart with UPGRADING, then NONE, once there has been no reason to roll back.

Month 4: tune and write it down.

  • On staging, test UCS and the trie memtable on the delivery events table with production-like load. Move only if p99 latency and compaction backlog improve, and change one thing at a time.
  • Decide whether to enable the built-in auto repair or stay with Reaper. Since the JVM property is irreversible, decide on paper first.
  • Write a runbook for node replacement, disk full, repair failure and restore, and rehearse node replacement once.

What we did not choose and why. ScyllaDB might run the same workload on fewer cores, and its tablets and Manager would reduce toil, but Sukhna’s 12 TB of provisioned disk is over the free limit, and changing engines in the same year as fixing the data model doubles the risk. We would revisit it in a year with a priced quote and a proof of concept. YCQL would remove repair and give strong consistency, but the workload does not need transactions, YCQL lacks features the support scripts use (multi-row deletes and GROUP BY), and a four person team would be learning a new database at the same time.

When not to adopt each

  • Do not adopt Apache Cassandra if you need transactions across partitions today, if your team cannot commit to scheduled repair and upgrades, or if your data fits comfortably on one PostgreSQL server with read replicas. A small dataset does not become easier in a distributed database.
  • Do not adopt ScyllaDB if you need an open source licence for policy or distribution reasons, if you are a past or current ScyllaDB customer hoping to use the free tier, if your footprint will cross 10 TB or 50 vCPUs and there is no budget for a licence, or if you want to offer the database as a service to others.
  • Do not adopt YugabyteDB YCQL if you are moving an existing Cassandra application unchanged, if you rely on materialised views, UDFs, multi-row deletes or tunable consistency for write latency, or if your main need is maximum write throughput at eventual consistency. Also think twice if you would be better served by YSQL and real SQL.
  • Do not adopt any of them for ad-hoc analytics, full-text search over large corpora, or relational reporting. Pair them with an analytical store or a search engine instead.

A short history

  • 2007 to 2008. Avinash Lakshman and Prashant Malik built Cassandra at Facebook for inbox search, combining ideas from Amazon’s Dynamo paper (2007) and Google’s Bigtable paper (2006). Facebook released it as open source in 2008.
  • 2009 to 2010. Cassandra entered the Apache Incubator and became an Apache top-level project in 2010. Version 0.6 shipped in April 2010 and 1.0 in October 2011.
  • 2011 to 2013. CQL arrived and became the main interface, replacing Thrift for most users. Cassandra 2.0 followed in September 2013 with lightweight transactions.
  • 2015 to 2016. ScyllaDB, from the team behind the Seastar framework, released its first GA version under AGPL. Yugabyte was founded in 2016 by former Facebook engineers who had worked on HBase and Cassandra.
  • 2017 to 2024. Cassandra 3.11.0 arrived in October 2017 and became the long running stable line. Cassandra 4.0 shipped in July 2021 after a long focus on correctness, 4.1 in December 2022 and 5.0 in September 2024. YugabyteDB moved all database features to Apache 2.0 in 2019. ScyllaDB announced its move to source-available in December 2024.
  • 2025 to 2026. ScyllaDB 2025.1 became the first source-available release, IBM completed its acquisition of DataStax in May 2025, ScyllaDB limited its free licence to never-customers in April 2026, and Cassandra 6.0 alphas brought Accord and Transactional Cluster Metadata.

Decision guide

You run Cassandra 3.11 or 4.0 and the cluster mostly works

Upgrade to 4.1, then 5.0, on your current hardware. Fix the data model and the repair schedule in the same project. Evaluate the 5.0 storage features one by one after the storage compatibility step.

You need lower latency per core and want a vendor to call

Run a proof of concept on ScyllaDB with your fixed data model, get a priced quote for your total storage and vCPUs across every environment, and read the licence with your legal team. If the numbers work, ScyllaDB’s tablets and Manager will save time.

You need strong consistency, unique indexes or multi-row transactions with a CQL-like API

Look at YugabyteDB YCQL for a new application, and compare it with YSQL on the same cluster. Expect to change your data access code; do not plan a driver swap.

You do not want to run nodes at all

Compare a managed CQL service against your queries and feature list, including which CQL features it supports and how it charges for reads, writes and storage. Keep an export path to plain Cassandra.

Your data is under a terabyte and grows slowly

Stay on PostgreSQL or MySQL with good indexes, partitioning and read replicas. Revisit this post when a single table or write rate truly outgrows one primary.

Checklist

  • The five main queries are written down, and each has a table designed for it.
  • Every partition key is bounded by time, hash bucket or both, and you know the largest partition size today.
  • Every table with deletes is repaired, completely, more often than its gc_grace_seconds.
  • TTL is used for data with a retention period, and TWCS or equivalent for append-only time data.
  • No query in production depends on a secondary index without a partition key restriction, unless its volume is known and low.
  • The cluster is on a maintained release line, and drivers are on maintained versions.
  • Backups go to object storage outside the cluster, and a restore to a separate cluster has been tested this quarter.
  • Disk usage alerts fire well before compaction headroom runs out.
  • p99 latency, pending compactions, tombstones per read and dropped messages are on a dashboard someone looks at.
  • The licence terms are checked against your total footprint, including staging and CI.
  • The upgrade path for the next two years is written down, including storage format steps.
  • Node replacement has been rehearsed.

Common mistakes

  • Keying by tenant and day. It looks bounded but grows with your biggest customer. Add a hash bucket or a finer key.
  • Treating secondary indexes like relational indexes. Without a partition key, a query asks many nodes. Use SAI with care and know the fan-out.
  • Skipping repair because “nothing is broken”. Missed repairs show up later as resurrected deletes and inconsistent reads.
  • Deleting rows one by one at scale. Use TTL and time windows; let compaction drop whole SSTables.
  • Turning on every new 5.0 feature during the upgrade. Upgrade the binaries first, then storage compatibility, then one storage feature at a time.
  • Counting only data size for the ScyllaDB free tier. The limit is total available storage and vCPUs across all clusters.
  • Expecting YCQL to run Cassandra code unchanged. Consistency rules, timestamps and missing features differ.
  • Reading vendor benchmarks as capacity plans. Size from your own test at your own consistency level.
  • Running nodes with nearly full disks. Compaction needs room; a full disk is an outage.

A small hands-on check

We did not run a drill for this post. The test box does not have Java installed, and the brief for this post allowed a small loopback test only if it needed no new system packages. So we did not start Cassandra, ScyllaDB or YugabyteDB, and nothing in this post comes from our own measurements. The behaviour described here comes from the projects’ release notes, NEWS.txt and configuration files, documentation, licence texts and vendor pages listed below.

For a quick check of your own, a single Cassandra 5.0.9 tarball on a laptop with Java 17, bound to 127.0.0.1, is enough to create the inbox table above, load a few thousand rows, and compare nodetool tablestats and tracing output for the old and new partition keys.

Unlearn, re-learn

  • Unlearn “Cassandra is slow” or “Cassandra is fast”. Re-learn that partition design decides most of the latency you will see, on any of these engines.
  • Unlearn “secondary indexes make it like SQL”. Re-learn that every query should name a partition, and that SAI is a tool for narrowing, not for scanning.
  • Unlearn “repair is an admin chore”. Re-learn that repair is part of correctness, tied to gc_grace_seconds and deletes.
  • Unlearn “CQL compatible means drop-in”. Re-learn that ScyllaDB and YCQL differ from Cassandra in features, consistency and licence, and test every query.
  • Unlearn “source available is the same as open source”. Re-learn to read who may use the free licence, up to what size, and what happens after you buy anything.
  • Practise a node replacement and a restore every quarter, and apply one storage change at a time with numbers before and after.

Sources

Apache Cassandra

ScyllaDB

YugabyteDB YCQL

Around them

comments powered by Disqus

Releted Posts

Distributed coordination in 2026: revisit etcd, ZooKeeper and Consul before you write another leader election

Most teams do not decide to build a distributed coordination system. It creeps in. A scheduled job runs on one VM.

Read more

Data transformation in 2026: revisit dbt Core v1, dbt v2 and SQLMesh before you write another SQL model

Almost every reporting database has a folder of SQL that nobody fully owns. It starts with one view for daily sales.

Read more

Stream processing in 2026: revisit Apache Flink, RisingWave and Arroyo before you write another consumer that keeps state

Most teams that use Kafka have at least one consumer that does more than it should. It started as a simple loop that read events and wrote them somewhere.

Read more