Cassandra 5.0 beta brings indexing and storage changes together

Cassandra 5.0's first beta puts new query capabilities beside changes to the machinery that retrieves stored rows. The beta1 changelog opens with a fix for SAI intersection queries, CASSANDRA-19011. It also records fixes involving composite partitions and intersections between static and non-static rows. Those entries describe a substantial part of the work between adding an index and making that index behave correctly with the database's data model.

The December 5 beta is available for evaluation of a release that includes vector search, Storage-Attached Indexes and new trie-based storage implementations. These capabilities affect different operations. Vector search introduces a way to ask for nearby values. SAI supplies secondary indexing integrated with Cassandra storage. Trie memtables and trie-indexed SSTables change how the database organizes and finds data in memory and on disk.

I find that combination more interesting than vector search considered alone. Cassandra's appeal to me is its ability to support active-active systems at scale when the application actually needs that architecture. Query flexibility matters within that decision, along with the cost of maintaining and retrieving the underlying data.

Correctness across the indexing lifecycle

The beta's SAI changes cover more than the evaluation of a predicate. CASSANDRA-19017 addresses validation of empty column indexes after full-SSTable streaming. CASSANDRA-19032 concerns indexes being marked queryable during truncation. These are transitions in the life of indexed data. They occur when the database transfers stored files or removes a table's contents, outside the simple sequence of creating an index and issuing a query.

The SAI README in the beta tag explains why these transitions matter. SAI is a local secondary index implementation whose on-disk components can accompany entire-SSTable streaming. Those components also participate in snapshots. An index therefore has to preserve meaningful state while the database performs operations on the associated SSTables.

Query planning has its own interactions. The changelog records improved handling of indexed and non-indexed columns in queries under CASSANDRA-18166. CASSANDRA-19040 fixes unindexed contexts that did not consider CONTAINS KEY. The intersection fixes sit in that broader set of changes. Supporting a column index requires the query implementation to account for the other restrictions in the statement and for the structure of the rows it reads.

The release also fixes incorrect seeking through an SSTable iterator by IndexState, recorded as CASSANDRA-18932. This is a separate entry from the SAI intersection fix. Both belong in an assessment of the beta because an index lookup ultimately depends on retrieving the intended stored data. The changelog supports those specific descriptions, without establishing that every possible indexing defect has been eliminated.

SAI's storage design gives several indexes on a table shared row-location information. The README says related offsets and token information are stored once per SSTable. It also says index updates are synchronous with mutations and do not require a read before the write. These mechanisms explain how the implementation connects column indexes to the database's existing write and storage paths.

What vector search adds to the query model

The beta release notes describe a fixed-length vector type with an element type and dimension. They separately list cosine, Euclidean and dot-product similarity functions. Approximate nearest-neighbor search uses SAI indexes through ORDER BY ANN OF, with the jvector library providing the search implementation.

These pieces have different responsibilities. A vector type represents a value in a schema. A similarity function computes a relationship between supplied values. Indexed nearest-neighbor search retrieves candidate rows according to that relationship. Alpha2 introduced the indexed search capability, and the beta changelog retains that history. Beta1 develops a release that already has the query operation.

The project's December 5 explanation of vector search identifies similarity retrieval as the motivation. It discusses document retrieval and recommendation applications, among other uses. The concrete architectural attraction is performing similarity calculations and ranking inside the database, where the associated records reside.

That can reduce the amount of data an application must transfer elsewhere to perform retrieval. It does not establish a universal latency improvement. The release notes explicitly describe the search as approximate, which is part of the operation's meaning. An application choosing the feature is choosing that retrieval behavior alongside its representation of the data.

My enthusiasm for this addition comes from the possibility of using a database already justified by the application's availability needs. A vector query alone is insufficient reason to adopt Cassandra's distributed architecture. For an application that needs both capabilities, the beta provides them in the same database implementation.

Two different uses of tries

The storage changes deserve separate treatment because trie-based primary lookup and secondary indexing solve different problems. Branimir Lambov's November 9 explanation describes memtables and SSTable indexes built around tries and byte-comparable representations of database keys. Memtables hold recently updated data before it flushes to disk. SSTables hold immutable sets of stored data.

The memtable API documentation in beta1 supplies a more specific account of the memory change. TrieMemtable organizes partitions in an in-memory trie and places the partition indexing structure in a buffer. That buffer can be off heap. The purpose includes reducing garbage collection work while improving the compactness and lookup behavior of the indexing structure. Selection happens through named configurations. A minimal definition in cassandra.yaml can name the trie implementation:

memtable:
    configurations:
        trie:
            class_name: TrieMemtable

For an existing table called events, the table property selects that configuration. Tables without an explicit selection continue to use the configuration named default, so defining trie alone does not switch every table:

ALTER TABLE events WITH memtable = 'trie';

The documentation says the selection propagates through the table schema, while the named configuration must be available on each node. A node that cannot instantiate the selected configuration logs an error and falls back to its default. A shared table property therefore depends on node-local configuration being present across the cluster.

The trie-indexed SSTable format concerns persistent lookup. The beta notes say it removes the index summary component and does not require key caching. They also describe efficient lookup within partitions containing very large numbers of rows. Lambov's article explains that the trie index uses a layout organized around disk pages. These changes concern locating records within the primary storage format, independently of whether an application defines a secondary index.

The notes identify bti as the format selected through the SSTable configuration. Installing the beta does not imply that a table has selected TrieMemtable or that every stored file has acquired the new format. The explicit choices allow evaluation to distinguish a query capability from a particular memory or disk representation.

The beta changes ordinary disk access too

CASSANDRA-19021 changes the default disk_access_mode to mmap_index_only. The configuration shipped with beta1 explains that this maps index files while leaving data files outside that memory-mapping policy. Its description of auto enables mapping for both data and index files on a 64-bit JVM. The upgrade notes provide the explicit setting for retaining the previous default behavior:

disk_access_mode: auto

This is relevant even when no vector column or new memtable configuration is involved. An upgrade can change how the same stored data reaches the process because a default has changed. Comparing two versions without recording this setting would combine a binary change with a disk access policy change.

The beta also adds direct I/O support for commit-log files through Java native APIs. The release notes describe user-space buffers as the means of reducing cache effects and memory-mapping overhead. Commit-log I/O and SSTable reads are separate operations, so this addition should not be read as a statement that all database I/O now uses a single policy.

Compatibility controls the storage transition

The release notes make storage compatibility an explicit setting. Its default, CASSANDRA_4, keeps SSTables, commit logs, hints and messaging compatible with Cassandra 4.x. The documented process first upgrades the binaries in that mode. A rolling restart into UPGRADING then permits the cluster to adopt the new storage version, followed by a restart into NONE after the transition.

One visible consequence is the maximum expiration timestamp. The notes extend it to February 7, 2106, while compatibility mode retains the January 19, 2038 limit. A cluster running new binaries therefore does not automatically gain the extended range. The storage transition determines when the range becomes available, because the persisted representation must remain interpretable by the participating nodes.

This makes rollback and feature activation part of the same operational decision. The notes describe rollback to the previous version while the cluster remains in the Cassandra 4 compatibility mode. Enabling the new storage behavior is a later step with a different compatibility state.

I consider that separation useful for evaluating a major database release. It allows the effects of running new binaries to be examined before changing every storage assumption. The beta's notes also raise the minimum Python version for cqlsh to 3.7, while Java 11 remains the minimum server runtime and Java 17 remains experimental. Evaluation includes the client tooling and storage settings as well as the queries the application sends.