---
title: "Performance and sizing"
slug: "dev-vector-search-operations-performance"
description: "Explore VAST Vector Search performance, indexing, and query optimization to enhance your cluster's efficiency and manage resource allocation effectively."
updated: 2026-10-30T18:18:51Z
published: 2026-10-30T18:18:51Z
canonical: "docs.vastdata.com/dev-vector-search-operations-performance"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vastdata.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Performance and sizing

*Applies to VAST Cluster 5.5.*

This page covers cluster-level performance and sizing for VAST Vector Search: the state of the index, what a search reads, how load spreads, what a vector table costs in space, and what your platform team can see. How to write the query itself is in [query design](/develop/docs/dev-vector-search-guides-query-design). There are no published capacity or throughput figures for VAST Vector Search on 5.5, so measure with your own data.

## What you control and what the cluster controls

| Area | Who controls it | Where to read more |
| --- | --- | --- |
| Metric, element type, dimension and quantization | You, when you create the table (none can be changed later) | [Create an index](/develop/docs/dev-vector-search-guides-create-an-index), [quantization](/develop/docs/dev-vector-search-guides-quantization) |
| The query shape, the columns and `LIMIT` | You | [Ask for less](/develop/docs/dev-vector-search-operations-performance#ask-for-less) |
| Probe settings for a session | You | [Search session settings](/develop/docs/dev-vector-search-reference-configuration) |
| Client connections and how they spread | You | [Spread the load](/develop/docs/dev-vector-search-operations-performance#spread-the-load) |
| Background clustering of the index | The cluster | [Check the index first](/develop/docs/dev-vector-search-operations-performance#check-the-index-first) |
| The Query Engine pool and the database pool | Platform team | [Cluster settings to ask about](/develop/docs/dev-vector-search-operations-performance#cluster-settings-to-ask-about) |

Vector search runs in the VAST Query Engine, which is built into the CNodes. So searches use CNode CPU and memory, shared with the cluster's other work, including the background work that builds and refines the index.

## Check the index first

A latency or recall number means little while the index is still being built. Newly inserted vectors can be searched straight away, while the index is updated in the background. Until then, a search reads those recent rows directly, outside the index, so right after a large load each search does more work than it will once the index has caught up. The background clustering also competes with your queries for CNode CPU.

Each vector index reports how far its background clustering has got:

| Field | Meaning |
| --- | --- |
| `clustering_progress` | Clustering progress as a percentage, 0 to 100 |
| `clustering_progress_label` | The same progress as a grade: `A+`, `A`, `B` or `C`. A higher grade means more progress. |

A new, empty table starts at `0` and `C`. Read them with `GET /tables/show/` in the VMS REST API ([CI/CD and automation](/develop/docs/dev-vector-search-operations-ci-cd#check-the-index)), or ask your platform team, who see the grade in the table's view in the VAST Web UI.

A grade of `C` doesn't mean the index isn't used. A table of 1.2 million rows can stay at `0` and `C` for over an hour after loading, while its searches already read the index ([what your platform team can see](/develop/docs/dev-vector-search-operations-performance#what-your-platform-team-can-see) shows how to tell). While the background work runs, the row count that `GET /tables/show/` and the SDK's table statistics report can be higher than the number of rows in the table; it comes back to the right number when the work finishes. Count rows with `SELECT count(*)` instead.

Run load tests when the grade is `A` or `A+` and the cluster isn't busy loading. Otherwise, accept that you're measuring the extra cost of recent rows.

## Ask for less

- **Use the index's query shape.** A search that doesn't match it still runs, but it scans the whole table instead of walking the index, and one such query on a big table uses a lot of CNode CPU that other users of the cluster feel. The shape is in [query design](/develop/docs/dev-vector-search-guides-query-design).
- **Return only the columns you need.** Selecting the embedding column, or many wide columns, moves more data over the network for every result row.
- **Keep `LIMIT` to what you use.** A larger `LIMIT` returns more rows, and more data, for every search.
- **Raise probes only when you've measured.** The probe settings control how many clusters a search reads at each level of the index. The defaults are the supported starting point. Raising them generally improves recall and costs latency, CPU and memory, because each search reads more clusters. When you compare runs, pin the minimum and maximum to the same values so that every query reads the same amount. The settings are in [search session settings](/develop/docs/dev-vector-search-reference-configuration), and how to measure the effect is in [developer observability](/develop/docs/dev-vector-search-guides-developer-observability).

Trino and Spark don't use the vector index ([limits](/develop/docs/dev-vector-search-reference-limits)). Search through the Query Engine.

## Spread the load

One ADBC connection doesn't show what the cluster can do. Each search in flight uses memory on a CNode, so open several connections and spread them over the Query Engine pool's addresses, as you would for any VAST DataBase workload ([spread work across endpoints](/develop/docs/dev-database-operations-performance#spread-work-across-endpoints)). A connection stays on the address you give it, and so does every connection to the same address: nothing spreads them for you. Ask your platform team to watch CNode CPU while you load-test: if one CNode is busy and the rest are idle, your connections aren't spreading.

## Quantization

`scalar_8bit` quantization (the default) uses less space, CPU and memory than `none`, at some cost in recall. You can't change it after the table is created, so measure first: build a sample table each way, compare recall at your `LIMIT` (Recall@K) against a `none`/`none` table or an exact search, and then create the real table. The settings and their allowed combinations are in [quantization](/develop/docs/dev-vector-search-guides-quantization).

## Your data

Real embeddings form clusters, and the index relies on that. Random data, such as Gaussian noise, doesn't cluster, so a test with random vectors shows worse recall and latency than you'll get with real embeddings. A mismatch between the metric and your embeddings (cosine against L2, or unnormalized vectors with inner product) also looks like a slow or wrong index. Check the embedding model's documentation for the metric it was trained for.

## Space

A vector column takes roughly *rows × dimensions × bytes per element*: 4 bytes for `VECTOR(FLOAT, d)` and 2 for `VECTOR(FLOAT16, d)`. On top of that, the index keeps its own structures, and how big they are depends on the quantization you choose when you create the table:

- `scalar_8bit` (the default) stores compact 8-bit codes for clustering and search.
- `none` keeps full-precision values, so it needs more space and memory.

There's also a maximum dimension, which depends on the cluster quantization, and `none` has the lower one ([limits](/develop/docs/dev-vector-search-reference-limits#index-rules)). A table with too many dimensions fails at `CREATE TABLE` with `vector dimension <d> exceeds max supported dimension <max> for clustering quantization type <type> due to memory limitations` ([errors](/develop/docs/dev-vector-search-troubleshooting-errors#creating-a-table)).

## Loading and searching use different pools

Bulk loads through the Python SDK or S3 go to the ordinary database endpoints, which can be spread over many CNodes. Searches go to the Query Engine pool. Size and test them separately, not as one pool. See [setup](/develop/docs/dev-vector-search-operations-setup#which-endpoint-does-what).

## What your platform team can see

| Signal | Where | What it tells you |
| --- | --- | --- |
| Clustering grade (`C` to `A+`) | The table's view in the VAST Web UI, or `GET /tables/show/` | Whether the index has caught up with your inserts ([check the index first](/develop/docs/dev-vector-search-operations-performance#check-the-index-first)) |
| CNode CPU | VAST Web UI analytics | Whether searches and background clustering compete for CPU, and whether load spreads over the CNodes |
| `top_n_num_processed_rows`, `top_n_num_returned_rows`, `top_n_query_latency_us` | The predefined VMS monitors `Cluster Vast DB TopN` and `CNode Vast DB TopN`, read with `GET /api/v8/monitors/<id>/query/` | How many rows the searches' top-*k* step compared. About the table's row count per search means the search scanned the table; a small fraction of it means it used the index. |
| `vec_index_scan_num_l1_reads` | An ad hoc VMS query: `GET /api/v8/monitors/ad_hoc_query/?object_type=cluster&prop_list=TabularQueryEngineMetrics,vec_index_scan_num_l1_reads` | Reads of the index's lowest level. Above zero, searches walked the index; zero for a search means it didn't use the index. |

The counters are cumulative for the whole cluster and are sampled at intervals. To see what your searches did, read them before and after a run on a quiet cluster, and divide the difference by the number of queries. On a table of 1.2 million rows, for example, an index search compares a small fraction of the rows and reads the index's lowest level; the same search written as a similarity ordered descending compares all 1.2 million rows per query and reads no index level. A developer can also check a single query with `EXPLAIN` ([query design](/develop/docs/dev-vector-search-guides-query-design#queries-that-dont-use-the-index)).

The general VAST DataBase metrics (query latency, running queries, rows scanned) are described in [what your platform team can see](/develop/docs/dev-database-operations-monitoring-your-workload#what-your-platform-team-can-see) for VAST DataBase. There are no vector-specific alerts or call-home events described for 5.5. Don't expect the cluster to alert you when the index falls behind; check the clustering grade.

**Admin task: send to your platform team.** Ask them to share the clustering grade of your tables, CNode CPU and the TopN counters during your load tests. See [Monitoring VAST DataBases](/docs-5-5/docs/monitoring-vast-databases).

## Cluster settings to ask about

**A Query Engine pool.** The VAST Query Engine needs its own virtual IP pool with the Query Engine role ([VAST Query Engine](/docs-5-5/docs/vast-query-engine#accessing-vast-databases-using-the-query-engine)). Ask how many CNodes and addresses it has: that's what your search connections spread over. A Query Engine pool can't be modified after it's created (5.5.0 release notes), so agree its size before a load test, not during one. See [setup](/develop/docs/dev-vector-search-operations-setup).

**A database pool for loading.** Bulk loads use the ordinary VAST DataBase pool; see [cluster settings to ask about](/develop/docs/dev-database-operations-performance#cluster-settings-to-ask-about) for VAST DataBase.

## See also

- [Query design](/develop/docs/dev-vector-search-guides-query-design): the query shape the index needs.
- [Search session settings](/develop/docs/dev-vector-search-reference-configuration): probe settings and their defaults.
- [Limits](/develop/docs/dev-vector-search-reference-limits): what can't be changed after creation.
- [VAST DataBase performance](/develop/docs/dev-database-operations-performance): general client-side advice.