# Vector Search FAQ Frequently asked questions about Vector Search in ScyllaDB. ## 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](https://cloud.docs.scylladb.com/stable/vector-search/work-with-vector-search.md#vs-similarity-functions) 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](https://cloud.docs.scylladb.com/stable/vector-search/work-with-vector-search.md#vs-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. However, you can recreate the index with a new configuration. ScyllaDB 2026.2+ Starting with ScyllaDB 2026.2, you can create a second vector index on the same column with the desired configuration. The old index continues serving queries while the new one is being built, and queries are automatically routed to the new index once it is ready. Then drop the old index: ```cql CREATE CUSTOM INDEX IF NOT EXISTS my_index_v2 ON myapp.comments(comment_vector) USING 'vector_index' WITH OPTIONS = { 'similarity_function': 'DOT_PRODUCT' }; -- After the new index is ready: DROP INDEX IF EXISTS my_index; ``` ScyllaDB < 2026.2 You must **drop the existing index** and **recreate it** with the new configuration. During the rebuild, similarity search is unavailable on the affected column: ```cql 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. For a zero-downtime migration procedure using a duplicate column, see [Altering a Vector Index](https://cloud.docs.scylladb.com/stable/vector-search/work-with-vector-search.md#vs-alter-index). ## 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](https://cloud.docs.scylladb.com/stable/vector-search/vector-search-filtering.md) for examples and details. ## Can I use Vector Search with Alternator (the DynamoDB API)? Yes. Starting with ScyllaDB 2026.2.0, you can use Vector Search through the DynamoDB-compatible Alternator API, storing embeddings as lists of numbers. The core workflow — storing vectors, building a vector index, and running ANN queries — is supported. Some CQL capabilities are **not** available through Alternator in the 2026.2.x series, including configurable similarity functions, similarity scores, metadata filtering, HNSW index tuning, and quantization. See [Vector Search with Alternator](https://cloud.docs.scylladb.com/stable/vector-search/vector-search-alternator.md) for details and Python examples. ## 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](https://cloud.docs.scylladb.com/stable/vector-search/vector-search-quantization.md) for configuration guidance. ## Are partition deletes and range deletes supported? **Partition deletes** (`DELETE FROM t WHERE pk = ?`) and **range deletes** (`DELETE FROM t WHERE pk = ? AND ck > ?`) on tables with clustering keys are **not** propagated to the vector index. ScyllaDB filters out deleted rows at query time, so they will not appear in ANN results. However, the stale entries in the vector index still consume candidate slots, which can cause ANN queries to return **fewer results than the requested LIMIT**. They also continue to consume memory on the vector search nodes. To avoid this, always delete rows using a fully specified primary key (all partition key and clustering key columns). See [CQL Features Not Supported](https://cloud.docs.scylladb.com/stable/vector-search/work-with-vector-search.md#vs-limitations) for details. ## How do I estimate the memory needed for my vector index? Use this simplified formula: $$ \text{Memory (bytes)} \approx N \times (D \times B + m \times 16) \times 1.2 $$ 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](https://cloud.docs.scylladb.com/stable/vector-search/vector-search-sizing.md). ## Do I need a Vector Search node in every Availability Zone? No. The recommended production topology places one Vector Search node in each Availability Zone (AZ) — so that every ScyllaDB node has a co-located vector index — but ScyllaDB Cloud also supports deploying **fewer Vector Search nodes than storage nodes**. For example, a three-node ScyllaDB cluster with a replication factor of 3 (RF=3) across three AZs can run with just **two Vector Search nodes**. Two nodes keep the vector index redundant (vector search survives the loss of one node) while lowering the cost of the Vector Search tier. The trade-offs are some cross-zone query traffic (negligible at low QPS), slightly higher latency for the one AZ that has no local Vector Search node, and high availability that becomes **regional rather than zonal**. See [Node Placement and Availability Zones](https://cloud.docs.scylladb.com/stable/vector-search/vector-search-clusters.md#vs-node-placement) for a full comparison of the two topologies and guidance on when to choose each. ## 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](https://cloud.docs.scylladb.com/stable/vector-search/vector-search-concepts.md#vs-concepts-embeddings) 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](https://cloud.docs.scylladb.com/stable/vector-search/vector-search-concepts.md#vs-concepts-hnsw-params). ## 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? Yes. Starting with **ScyllaDB 2026.2.0**, vector-indexed tables support automatic row expiration through ScyllaDB’s *per-row TTL* feature. You designate one column as the expiration-time column with the `TTL` keyword. When a row’s expiration time passes, ScyllaDB deletes the row and the Vector Store removes it from the index, so it no longer appears in `ANN OF` query results. ```cql CREATE TABLE myapp.sessions ( id uuid PRIMARY KEY, embedding vector, expire_at bigint TTL -- seconds since the UNIX epoch ); CREATE CUSTOM INDEX ann_idx ON myapp.sessions(embedding) USING 'vector_index'; -- The row is removed from the table and the vector index once expire_at passes. INSERT INTO myapp.sessions (id, embedding, expire_at) VALUES (uuid(), [0.1, 0.15, 0.3, 0.12, 0.05], 1784311784); ``` See [Row Expiration with Per-Row TTL](https://cloud.docs.scylladb.com/stable/vector-search/work-with-vector-search.md#vs-ttl) for supported column types, expiration timing, and how to manage the TTL column on an existing table. ## How do I alter a vector index (change similarity function or HNSW parameters)? You cannot alter a vector index after creation. However, you can recreate the index with a new configuration. ScyllaDB 2026.2+ Starting with ScyllaDB 2026.2, you can create a second vector index on the same column. The old index continues serving queries while the new one is being built, and queries are automatically routed to the new index once it is ready: 1. Ensure enough memory for both indexes on the Vector Search instances. 2. Create the new index on the same column with a different name. 3. Wait for the new index to finish building (queries keep using the old index automatically). 4. Drop the old index. 5. Resize the instance down if memory allows. ScyllaDB < 2026.2 On versions prior to 2026.2, a single vector column can only have one index at a time. To change the index configuration you must migrate to a new column: 1. Add a duplicate vector column to the table. 2. Dual-write embeddings to both the original and new columns. 3. Backfill the new column for all existing rows. 4. Ensure enough memory for both indexes on the Vector Search instances. 5. Create the new index (with updated options) on the duplicate column. 6. Switch your application queries to the new column. 7. Drop the old index and column. 8. Resize the instance down if memory allows. See [Altering a Vector Index](https://cloud.docs.scylladb.com/stable/vector-search/work-with-vector-search.md#vs-alter-index) in the Working with Vector Search page for a step-by-step walkthrough with examples. ## 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(, )` * `similarity_euclidean(, )` * `similarity_dot_product(, )` Each argument can be either a vector column name or a vector literal. Both arguments must have the same dimension. For example: ```cql 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. #### NOTE `similarity_dot_product` assumes that all input vectors are L2-normalized. Supplying non-normalized vectors will produce values that are not meaningful for similarity comparison. If your vectors are not normalized, use `similarity_cosine` instead. ## What’s Next * [Working with Vector Search](https://cloud.docs.scylladb.com/stable/vector-search/work-with-vector-search.md) — CQL syntax for vector tables, indexes, and ANN queries. * [Vector Search Concepts](https://cloud.docs.scylladb.com/stable/vector-search/vector-search-concepts.md) — deep dive into HNSW, similarity functions, and architecture. * [Troubleshooting](https://cloud.docs.scylladb.com/stable/vector-search/vector-search-troubleshooting.md) — common issues and solutions.