VAST VectorStore

Recap: embeddings & vector search

An embedding model turns content into a vector, and retrieval is a nearest-neighbor search over those vectors - see embeddings and vector search fundamentals for how closeness is measured. VAST exposes three distance functions as built-in SQL: Euclidean, cosine distance, and the negative inner product. This page is about what changes when vectors live inside the data platform instead of a bolt-on vector DB.

Vectors as a first-class type, co-located with source data

In VAST, a vector is a first-class column stored in the same table as its metadata and source content. There is no separate vector database to keep in sync, and no two-step “search the index, then fetch the document from object storage” hop. Inserting a row and its vector is a single atomic transaction - strong consistency, versus the eventual consistency you inherit when vectors live in an external store that an ETL job has to catch up to. Access controls on the vector can't drift from the source data's ACLs, because they are the same row. (For the drift and second-hop costs of a standalone store, see the separate vector DB problem.)

The scaling wall of shared-nothing vector search

Most vector databases are shared-nothing, and memory-resident indexes like HNSW and FAISS are only fast while the entire index lives in RAM - so at billions of vectors the index gets sharded, and every query must scatter to every shard while the coordinator gathers and re-ranks. Race a query through both designs below and toggle a shard to overloaded: the slowest shard sets the latency - or fails the query - for everyone.

VAST removes the shards rather than managing them. In its Disaggregated, Shared-Everything (DASE) architecture, stateless CNodes reach all of the storage over NVMe-oF, so no node owns a partition and there is nothing to fan out, rebalance, or spill; the index (next section) prunes ~1,000× the candidates per level. The design target is sub-200 ms similarity search at trillion-vector scale with no sharding and no index freezes; in benchmarks, 50 billion vectors on 8 CNodes answered in about 114-317 ms, depending on concurrency.

How the index scales: hierarchical clustering

The reason VAST can drop sharding is the shape of the index itself. Instead of one giant in-memory graph, vectors are organized into a recursive hierarchy of distance-clusters, each level summarized by centroids - think of a library organized into sections, shelves, then books, so you can find a title without walking every aisle. Each level holds up to ~1,000 of the level below, so capacity grows ~1,000× per level while search stays logarithmic.

Explore the two halves of the design below: the L0-L5 capacity hierarchy, and the background reclustering lifecycle - new vectors land in a fast non-clustered table and are organized in the background, taking the tree from messy, overlapping clusters to clean, well-separated ones.

Because the tree grows by adding levels rather than shards, scaling from billions to trillions needs no resharding, index freeze, or global rebalance, and continuous ingest never blocks queries. The documented ceiling is 256T rows (2⁴⁸) per table - the 50-billion proof point is roughly 0.02% of it.

Inside the walk: beam width & the ratio rule

The walk isn't a fixed top-k at each level. VAST carries a beam of the closest centroids and widens it toward the leaves, bounded by a per-level min/max and driven by a ratio rule: it keeps expanding a level while the distance to the farthest selected centroid stays within a set ratio (default 1.8) of the closest. The whole walk runs on 8-bit (int8) scalar-quantized codes; only the final leaf candidates are fetched at full precision and reranked. Tune the ratio and watch the work-versus-recall trade.

Benchmarked: 11× faster, ~91% lower cost

The architecture differences show up in numbers. On a 1-billion-vector, 128-dimension benchmark at 99% recall, VAST delivers roughly 11× the throughput of a leading disk-based shared-nothing system, at about 91% lower cost per thousand searches, because the vectors no longer have to sit in expensive RAM. At 50 billion vectors - a scale the comparison system was not tested at - VAST sustains over a thousand queries per second on just 8 CNodes. To see why RAM is the bill at this scale, size an index in the hyperscale memory calculator - a trillion-vector index can live on NVMe but not in DRAM.

Indexing at write, GPU search, and hybrid vector + SQL queries

Indexes are built at write time - zone maps, the vector index, and secondary indexes are all maintained on ingest, so there is no separate “build the index” batch job. Search runs on CPU or GPU algorithms, including NVIDIA CAGRA, without caching the whole index in GPU memory. Because data is laid out in small columnar chunks, the engine can prune irrelevant blocks early instead of scanning everything.

The payoff for co-location is the hybrid query: vector similarity and SQL metadata filters in a single statement - for example, the nearest neighbors to a query embedding, filtered to a brand and a price range, without round-tripping between two systems.

It is genuinely SQL, not a bolt-on API. Vectors are a first-class column (fixed-dimension PyArrow list types), and built-in distance functions - array_distance() for Euclidean and array_cosine_distance() for cosine similarity - drop straight into a query, so you WHERE-filter on metadata, ORDER BY similarity, and LIMIT to the top matches in one statement. Apps reach it over the Arrow stack (ADBC driver, the vastdb Python SDK), which keeps vectors and results in columnar form end to end.

GPUs accelerate more than model inference here - they speed up the whole vector pipeline. Index builds run about 4× faster on GPU (10 hours down to 2.5 hours) using NVIDIA's cuVS library, while ingesting on the order of a million vectors per second. For SQL, Sirius - an open-source GPU SQL engine from the University of Wisconsin-Madison, in technical preview on VAST - ran up to 20× faster than DuckDB on NVIDIA RTX PRO 6000 in benchmarks (the VAST DataBase page puts that next to its other Sirius figures).

One engine, every retrieval technique

Production retrieval usually means bolting extra techniques onto a vector DB - hybrid fusion, filtered ANN (ACORN), quantized rescoring, MMR diversity, GPU index builds. Because VAST stores vectors as a SQL column, most of these collapse into a single query path. Compare them technique by technique.

What you can configure

The vector column and its index expose a small, typed set of knobs at schema, index, and query level.

SELECT id, title
FROM docs
WHERE brand = 'acme'
  AND price < 50
ORDER BY
  array_cosine_distance(
    embedding, :query_vec)
LIMIT 10;

New in VAST AI OS 5.5

VAST AI OS 5.5, generally available since August 6, 2026, ships the index this page describes as the Hyperscale Vector Index: the hierarchical, quantized, DASE-persisted index above, with memory-bounded queries at trillion-vector scale - so latency plateaus as the dataset grows instead of degrading. The release also adds 50+ aggregation functions to the native query engine, and SQL-native partitioning: a partition layout you can declare on a table when it helps, on top of the per-chunk pruning that lets most VAST DataBase tables skip partition design entirely. In benchmarks against Iceberg-based tables, partitioned tables ran highly selective queries more than 60% faster and updates 200× faster, with about 20% lower aggregate runtime in one manufacturing workload.

End-to-end RAG on one platform

Because vectors are native, the whole retrieval loop runs on a single platform: ingest the source data, embed it with serverless functions or NVIDIA NIM, index it at write, and retrieve with hybrid queries - no ETL drift between the vectors and the documents they came from. That is the difference between a vector store you have to babysit and one that stays consistent by construction.

Key takeaways