Vector Search FAQ¶

What similarity functions does ScyllaDB support?¶

ScyllaDB supports three similarity functions for vector indexes:

• COSINE (default) — measures the angle between vectors. Best for normalized embeddings from text models.

• DOT_PRODUCT — computes the inner product. Useful when vector magnitude carries meaning.

• EUCLIDEAN — measures L2 (straight-line) distance. Best for spatial data.

See Choosing a Similarity Function for guidance on when to use each.

What is the maximum number of dimensions?¶

ScyllaDB supports vectors with dimensionality from 1 to 16,000. This is compatible with all major embedding models, including OpenAI (text-embedding-3-large at 3072 dimensions) and Cohere Embed.

How long until a new vector is searchable?¶

Newly inserted vectors are typically searchable within approximately 1 second (p50 latency), thanks to ScyllaDB’s fine-grained CDC reader. In the worst case, a change becomes visible within ~30 seconds (wide-framed CDC reader interval).

See Write-to-Query Latency for details.

Can I change the similarity function after creating an index?¶

No. Vector index options cannot be altered after creation. To change the similarity function (or any other index option), you must drop the existing index and recreate it with the new configuration:

DROP INDEX IF EXISTS my_index;
CREATE CUSTOM INDEX my_index ON myapp.comments(comment_vector)
USING 'vector_index'
WITH OPTIONS = { 'similarity_function': 'DOT_PRODUCT' };

The index will be rebuilt over the existing data when the new index is created.

Does ScyllaDB support filtering in vector search queries?¶

Yes. ScyllaDB supports filtered vector search using two types of indexes:

• Local (per-partition) vector indexes (recommended) — search only within a single partition’s index. This is the fastest approach. Design your schema so that columns you filter on are part of the partition key and use equality (=) operators.

• Global vector indexes — search the entire index space across all partitions. Always much slower than local indexes, especially as the dataset grows.

Avoid inequality (>, <, >=, <=) and IN operators in filtered vector queries - they force the database to scan a much larger portion of the index, with performance degrading proportionally to selectivity.

See Filtering for examples and details.

What is quantization and when should I use it?¶

Quantization reduces the precision of stored vectors to save memory. Instead of storing each dimension as a 4-byte float (f32), you can use:

• f16 (2 bytes) — negligible recall loss for most workloads.

• bf16 (2 bytes) — brain float, statistically equivalent to f16 for most models.

• i8 (1 byte) — ~4x compression on vector data.

• b1 (0.125 bytes) — ~32x compression on vector data; best with rescoring.

Note that quantization compresses only the vector data, not the HNSW graph structure, so actual total memory savings are always less than the per-dimension compression ratio. For example, i8 is 4x smaller per dimension than f32, but total index memory typically drops only ~3x.

Use quantization when your dataset is large enough that f32 indexes would exceed available memory. Combine with oversampling and rescoring to recover accuracy.

See Quantization and Rescoring for configuration guidance.

How do I estimate the memory needed for my vector index?¶

Use this simplified formula:

Where N = number of vectors, D = dimensions, B = bytes per dimension (4 for f32, 2 for f16, 1 for i8), and m = maximum_node_connections (default: 16).

For worked examples, see the Sizing Guide.

Does ScyllaDB generate embeddings?¶

No. ScyllaDB stores and indexes vectors but does not generate them. Your application must use an external embedding model (OpenAI, Cohere, sentence-transformers, etc.) to produce vectors, then insert them into ScyllaDB.

See How Embeddings Work in the Concepts page.

Do I need to use the same embedding model for indexing and querying?¶

Yes. Vectors from different models exist in incompatible vector spaces and cannot be meaningfully compared. If you change your embedding model, you must re-embed all existing data. You can update the embeddings for all rows in the table and they will be refreshed in the index, but for performance reasons it is better to drop the index, update the data, and rebuild the index from scratch.

Why do vector tables require tablets-enabled keyspaces?¶

The HNSW vector index relies on ScyllaDB’s tablets data distribution mechanism for efficient data routing and sharding. Tablets provide fine-grained load balancing and dynamic rebalancing that the vector index depends on.

All ScyllaDB versions currently used by ScyllaDB Cloud enable tablets by default. If you still use a vnode-based cluster, you can create a separate tablets-enabled keyspace specifically for storing embeddings to overcome this limitation.

What does “recall” mean for vector search?¶

Recall is the fraction of true nearest neighbors found by the approximate search. A recall of 0.95 means 95% of the results match what an exact brute-force search would return. The remaining 5% are still genuinely similar vectors — they are just not the very closest ones.

You can increase recall by raising search_beam_width (ef_search), at the cost of higher query latency. See HNSW Parameters Explained.

Can I run exact (brute-force) vector search in ScyllaDB?¶

ScyllaDB’s vector search uses ANN (Approximate Nearest Neighbor) via the HNSW algorithm. There is no dedicated exact KNN mode. However, for small datasets, you can set a very high search_beam_width to achieve near-perfect recall.

For most use cases, ANN with default parameters provides recall above 0.95, which is functionally equivalent to exact search.

Is TTL supported on vector-indexed columns?¶

No. TTL (Time to Live) is not currently supported for vector-indexed columns. Writes with TTL on a column with a vector index are silently accepted but the TTL is ignored. See CQL Features Not Supported for the full list.

Support for TTL on vector-indexed columns is implemented in the upcoming ScyllaDB 2026.2.0 release.

Can I get similarity distance scores in query results?¶

Yes. You can retrieve similarity scores by calling one of the built-in similarity functions in your SELECT query:

• similarity_cosine(<vector>, <vector>)

• similarity_euclidean(<vector>, <vector>)

• similarity_dot_product(<vector>, <vector>)

Each argument can be either a vector column name or a vector literal. Both arguments must have the same dimension.

For example:

SELECT comment, similarity_cosine(comment_vector, [0.1, 0.15, 0.3, 0.12, 0.05])
  FROM myapp.comments_vs;

Each function returns a float value in the range [0, 1], where values closer to 1 indicate greater similarity. The similarity_euclidean and similarity_dot_product functions do not perform vector normalization prior to computing similarity.

What’s Next¶

• Working with Vector Search — CQL syntax for vector tables, indexes, and ANN queries.

• Vector Search Concepts — deep dive into HNSW, similarity functions, and architecture.

• Troubleshooting — common issues and solutions.