Cassandra alpha2 adds vector search to storage-attached indexing

Cassandra's second 5.0 alpha brings an important part of the proposed release into executable form. The tagged changelog records CASSANDRA-18715, which adds vector search to Storage-Attached Indexes, or SAI. A vector column and similarity functions were already present in the first alpha. Searching an index for nearby vectors is the addition in this release. That distinction matters to anyone deciding what a particular preview can demonstrate.

The release vote result on November 4 reports six positive votes, including three binding votes. Discussion that day also turns toward beta and the correctness issues that should block it. The combination makes this a useful point to examine the release. New query behavior is available, while the community is still deciding which guarantees must hold before the next stage.

I am interested in Cassandra because of the difficult availability problem it addresses, particularly for systems that need active-active operation at scale. Adding a query capability to that database is interesting when it fits the existing storage and operational model. The alpha2 changes make that fit more concrete.

A vector value becomes an indexed query

The alpha2 release notes distinguish the fixed-length vector<element_type, dimension> type from ANN search. They list cosine, Euclidean and dot-product similarity functions separately. ANN search uses the ORDER BY ANN OF syntax with SAI indexes and the jvector library. Storing an array of numbers, calculating similarity and retrieving nearby rows are separate pieces of functionality.

That separation explains why the alpha2 entry is substantial. A scalar similarity function provides a calculation on supplied values. An index supplies a way to retrieve candidates for a query. The release notes call this search approximate, so the interface should be understood as a nearest-neighbor retrieval facility with that qualification. The notes do not establish an exact-search guarantee or a workload-independent performance result.

The surrounding changelog entries show the work needed to make vectors participate in the rest of Cassandra. CASSANDRA-18964 fixes schema loading when user-defined types contain vectors that themselves contain user-defined types. CASSANDRA-18889 makes the vector type support the dynamic masking function mask_default. CASSANDRA-18876 removes support for empty vector values. These changes address the type's behavior in schema reconstruction, masking and value validation.

Those details matter when a vector stops being an isolated demonstration column. A database type participates in existing operations wherever the schema permits it. A successful nearest-neighbor query alone says little about whether those other operations behave correctly. Alpha2's changes show both query implementation and work on the rules around the values it searches.

The storage arrangement behind SAI

The SAI README in the alpha2 tag describes a column-based local secondary index. It traces the design to SASI, while explaining that SAI replaces the on-disk index formats for strings and numbers. Strings use a byte-ordered trie. Numeric values use a block-oriented balanced tree. These are descriptions of the scalar indexes, and should not be mistaken for a description of the vector-search algorithm.

SAI also changes how multiple column indexes share information. Related offsets and token information live once at the SSTable level. Indexes remain column-oriented in their CQL definition, but they can share the information needed to locate rows. That arrangement reduces duplicated on-disk metadata when a table has several indexed columns.

The same README says index updates occur synchronously with mutations, without a read-before-write operation. Global queries use Cassandra range reads. This preserves an important distinction between local indexing and distributed execution. A local index helps a node find matching data. A query across the cluster still needs the database's distributed read machinery.

Operational integration is part of the design too. SAI includes on-disk index components in snapshots and can stream those components when entire SSTables stream. Index builds appear as compactions and execute on compaction threads. These choices give operators existing mechanisms through which to observe and manage indexing work. They also mean indexing consumes resources within processes already responsible for managing stored data.

For a simple scalar example, the tagged README supports a table and index of this form inside an existing keyspace:

CREATE TABLE person (
    id int PRIMARY KEY,
    name text,
    age int
);

CREATE INDEX ON person (age) USING 'sai';

SELECT * FROM person WHERE age >= 18 AND age <= 35;

The query expresses a range over a non-primary-key column. The example illustrates the underlying indexing facility on which alpha2 adds vector search. It does not demonstrate ANN ordering, and it makes no claim about the cost of the distributed query.

What advancing to beta actually requires

The November 4 mailing-list discussion separates interface changes from release blockers. Mick Semb Wever asks participants to mark bugs for the beta fix version. He explains that if no remaining tickets require API changes, another alpha may be unnecessary. That is a statement about the kind of work remaining, not a declaration that every blocking defect has disappeared.

Other participants focus on CASSANDRA-18993 and a suspected correctness problem. Benedict argues that the issue needs diagnosis and a fix before beta. C. Scott Andreas objects to releasing a beta with a known reproducible bug that can lose data or return an incorrect query response. The thread contains disagreement about what a beta may reasonably contain, which is useful context for interpreting the release stage.

I agree with treating incorrect results as a central release concern. Cassandra's attraction depends on the database remaining dependable while it distributes work. A larger set of queries increases the number of interactions that must preserve that property.

The discussion should also constrain any claim about the timetable. A proposed next release is a development goal. The vote establishes that alpha2 passed its release process. It does not establish that beta is finished or that the suspected issue has been resolved.

Existing deployment assumptions still change

The upgrade section in the tagged notes gives concrete examples of the work around the new capabilities. Java 8 support is removed, with Java 11 the minimum. Java 17 support remains experimental in these notes. An evaluation therefore has a runtime requirement independent of whether it exercises SAI.

Compression configuration also changes. The deprecated table parameters sstable_compression and chunk_length_kb have been removed. Their replacements are class and chunk_length_in_kb. The metrics-reporter-config integration has also been removed, with the notes directing users toward the reporting facilities in Dropwizard Metrics. These changes affect existing configuration and monitoring arrangements even for tables without vectors.

My preference is to adopt Cassandra when the system requires its distributed behavior. Alpha2 makes indexed retrieval a more substantial part of that decision, but the reason to operate Cassandra still needs to come from the application. For an existing deployment, the preview now provides a specific implementation to examine alongside the runtime and configuration changes documented in the same release.