If You Last Used Cassandra 3.11, You Might Not Recognize It Today Apache Cassandra 5.0.9 is the latest GA release as of September 2026, while Cassandra 6.0 remains pre-GA with alpha builds available, according to the Apache Cassandra project's download page. The 5.0 line adds Storage-Attached Indexing, the Unified Compaction Strategy, native vectors with approximate nearest-neighbor search, and Auto Repair (opt-in in the 5.0.8 backport), while 6.0 work covers Transactional Cluster Metadata and Accord cross-partition transactions. Earlier releases brought zero-copy streaming for eligible whole SSTables in 4.0, benchmarked at roughly a fivefold improvement, and the Guardrails Framework in 4.1. If You Last Used Cassandra 3.11, You Might Not Recognize It Today If you learned Cassandra around version 3.11, the advice was fairly consistent: design tables around queries, be careful with secondary indexes, choose a compaction strategy for each workload, and arrange repair scheduling yourself. For conditional updates, use lightweight transactions. For transactions spanning multiple partitions, expect to do more work outside the database. In consulting work, I still encounter 3.11 clusters operated according to that model. Much of it remains useful, but several limitations behind those recommendations have changed. Cassandra now has storage-integrated indexing, vector search, a more flexible compaction strategy, and built-in repair scheduling. The 6.0 work goes further into cluster metadata and transactions. As of September, 2026, Apache Cassandra 5.0.9 is the latest GA release https://cassandra.apache.org/ /download.html . Cassandra 6.0 remains pre-GA, with alpha builds available. That distinction matters: SAI is something to evaluate on the stable release; Accord is a reason to follow and test the next one. The interesting part is not that Cassandra gained more configuration knobs. It is that several old assumptions about how Cassandra must be queried and operated have started to loosen. A rough comparison looks like this: | Area | What changed | Release | |---|---|---| | Streaming | An eligible whole SSTable can use a zero-copy transfer path | 4.0 | | Operational limits | Guardrails provide configurable warnings and failures | 4.1 | | Secondary indexing | Storage-Attached Indexing, or SAI | 5.0 | | Compaction | Unified Compaction Strategy, or UCS | 5.0 | | Similarity queries | Native vectors and approximate nearest-neighbor search | 5.0 | | Repair scheduling | Auto Repair, with explicit opt-in in the 5.0 backport | 5.0.8+ | | Cluster metadata | Transactional Cluster Metadata | 6.0 work | | Cross-partition transactions | Accord integration | 6.0 work | I wrote about some of the older pitfalls in 7 mistakes when using Apache Cassandra https://blog.softwaremill.com/7-mistakes-when-using-apache-cassandra-51d2cf6df519 . The useful question now is which advice still follows from Cassandra's architecture and which reflected limitations of an older implementation. Cassandra 4.0 improved the cost of moving data Streaming transfers data between nodes during bootstrap, replacement, rebuild, repair, and topology changes. In a large cluster, it determines how long a node takes to become useful and how quickly lost replica data can be restored. Cassandra 4.0 introduced a zero-copy streaming path for eligible whole SSTables. Instead of deserializing their contents into Java objects and serializing them again, Cassandra can transfer the files more directly. Partial transfers and other cases still need the appropriate streaming path; the optimization does not apply to every transfer. The 4.0 streaming documentation https://cassandra.apache.org/doc/4.0/cassandra/new/streaming.html reports roughly a fivefold improvement in the benchmark used to introduce the feature. That is not a capacity estimate for every cluster, but it explains why the change mattered: less allocation and CPU work can leave more of the transfer limited by storage and network throughput. For a node holding terabytes of data, faster streaming can shorten replacement and reduce the time spent with missing replicas. It is an operational improvement even if the application's CQL stays exactly the same. Guardrails move some limits into the database Older Cassandra deployments often depended on conventions enforced in code review or runbooks. Avoid creating hundreds of tables. Keep collections bounded. Do not let an application issue queries over an uncontrolled number of partitions. Use ALLOW FILTERING carefully. The Guardrails Framework introduced in 4.1 https://cassandra.apache.org/doc/4.1/cassandra/new/index.html lets operators express some of these rules in Cassandra itself. Depending on the guardrail, a configuration can warn, reject an operation after a threshold, or disable a feature. Examples include table and index counts, collection sizes, and the number of partition keys selected by a query. ALLOW FILTERING can be disabled. Conceptually: A warning gives an application team a chance to fix growing usage before it reaches the failure threshold. A rejection prevents an operation that exceeds the configured limit. Neither replaces workload design, but both are more reliable than assuming every developer has read the same operational guide. Secondary-index advice needs to distinguish SAI from older indexes If you learned Cassandra years ago, there is a good chance somebody told you: Don't use secondary indexes. That advice was often justified. Traditional Cassandra secondary indexes could behave poorly at scale, especially when queries had to scatter across many partitions or index cardinality did not match the workload. Experienced teams often preferred another Cassandra pattern: create another table containing exactly the shape required by the query. Suppose we have users: CREATE TABLE users id uuid PRIMARY KEY, country text, age int, status text, name text ; and we need queries by country and age . The traditional Cassandra answer might be another table: users by country and age with an appropriate partition and clustering key. Then another query appears, and another table appears. That is not necessarily wrong - query-driven denormalization remains one of Cassandra's strengths. Cassandra 5.0 adds Storage-Attached Indexing. We can index the columns used for filtering: CREATE INDEX users country idx ON users country USING 'sai'; CREATE INDEX users age idx ON users age USING 'sai'; CREATE INDEX users status idx ON users status USING 'sai'; These examples assume an existing keyspace selected for the session. The CQL index documentation https://cassandra.apache.org/doc/latest/cassandra/developing/cql/create-custom-index.html covers the syntax and supported column types. SAI integrates indexes with memtables and SSTables. Reads combine results from those structures, and the index lifecycle follows the storage engine's flushes and compactions. It supports numeric ranges, combinations of indexed predicates, collection predicates, and text equality. For some access patterns, that can remove the need for an additional query-specific table. The operational benefit is also relevant. If the required filtering can stay in Cassandra, there may be no need to maintain another copy in an external indexing system, with its own replication, recovery, and monitoring. That only holds when SAI provides the query behavior the application needs. An index does not eliminate query fan-out SAI changes how Cassandra finds matching rows. It does not make a query over many partitions equivalent in cost to a lookup using one partition key. With the indexes above, we can filter by both country and age without ALLOW FILTERING : SELECT id, name, age FROM users WHERE country = 'PL' AND age = 30 AND age < 40; SAI supports combining indexed predicates with AND , as shown in the query documentation https://cassandra.apache.org/doc/stable/cassandra/developing/cql/indexing/sai/sai-query.html . This gives us an additional access pattern without maintaining another table. The physical layout remains different. A table partitioned by country, with age as a clustering column, can serve this query from the relevant country's replica set. In the users table, rows remain partitioned by ID, so an indexed query can require work across multiple token ranges. Supporting the same filter does not imply the same routing, ordering, or read cost. The users example is deliberately simple. Filtering by a common country or status can match a large part of the dataset. An index makes that query expressible and can reduce local scanning, but the distribution of values and the work across nodes still matter. For a frequent query with strict latency requirements, I would compare SAI against a table designed for that query using representative data. Measure the read latency and cluster work, then account for the write and storage costs of maintaining either indexes or denormalized tables. The old blanket advice to avoid secondary indexes is too broad. The replacement is to evaluate SAI for the access pattern, with partitioning and selectivity still part of the decision. UCS makes compaction behavior easier to adjust Cassandra operators have traditionally chosen among several compaction strategies: | Strategy | Typical reason to choose it | Cost to consider | |---|---|---| | STCS | Write-heavy workloads | More SSTables may need checking on reads | | LCS | Lower read amplification | More data rewritten during compaction | | TWCS | Time-series data with suitable TTL patterns | Effectiveness depends on timestamp and expiration behavior | Cassandra 5.0 adds Unified Compaction Strategy. The UCS documentation https://cassandra.apache.org/doc/latest/cassandra/managing/operating/compaction/ucs.html recommends it for most workloads and describes how to configure behavior resembling the older strategies. UCS exposes the tiered-versus-leveled trade-off through scaling parameters. Positive values favor tiered behavior, negative values favor leveled behavior, and different levels can use different settings. Sharding allows compaction work to run in parallel and helps control SSTable sizes on nodes holding large datasets. The parameters can be changed while the system is running without requiring a full recompaction solely to switch between those behaviors. This makes tuning less disruptive than treating the initial strategy as a permanent choice. It still requires measurement. A change that reduces read amplification can increase background write work. Existing SSTables also take time to move through compaction; changing a setting does not instantly produce a new layout. UCS gives operators a common mechanism for adjusting that balance, rather than removing the balance itself. Vector search can stay next to operational data Cassandra 5.0 introduces a native vector type and approximate nearest-neighbor search through SAI. A product can store both its operational fields and an embedding: CREATE TABLE products id uuid PRIMARY KEY, name text, description text, embedding vector