VAST Data
VAST VectorStore
AdvancedVector search native to the data platform - vectors live next to the source data, so RAG retrieves without a separate vector DB to sync.
Recap: embeddings & vector search
An embedding model turns text, an image, or a document into a vector - a list of a few hundred to a few thousand floating-point numbers that place semantically similar items near each other in space. Retrieval is then a nearest-neighbour search: embed the query, find the closest stored vectors, return their source rows. If that is new, start with RAG & Vector Search for the fundamentals. This page is about what changes when those vectors live inside the data platform instead of a bolt-on vector DB.
How “closeness” is actually measured
Nearest-neighbour search rests on a distance function, and VAST exposes three as built-in SQL: Euclidean (straight-line distance), cosine distance (the angle between vectors, ignoring magnitude), and the negative inner product (a magnitude-aware dot product). Drag the two vectors below and watch each formula recompute step by step - the same arithmetic runs across hundreds or thousands of dimensions in production.
Vector U
Vector V
array_distance
Euclidean (L2)
√((U.x-V.x)² + (U.y-V.y)²)
= √((100-150)² + (120-40)²)
94.34
array_cosine_distance
1 - cosine similarity
sim = 19800 / (156.2 × 155.2) = 0.817
0.183
array_negative_inner_product
-(U · V)
= -(100×150 + 120×40)
-19,800
A 2-D illustration of the same distance functions VAST exposes in SQL; production vectors have hundreds to thousands of dimensions, but the math is identical.
Which metric you pick changes what “similar” means: cosine treats two vectors pointing the same way as identical regardless of length, while Euclidean and inner product are sensitive to magnitude. Embedding models are typically trained for one of them, so the retrieval query must match.
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.
The retrieval data path
Vectors live in a separate system from their source data - every write becomes an ETL hop, and every read becomes two.
Source data + metadata
in the object store / lakehouse
ETL / embedding job
batch - runs on a schedule
Push vectors to external DB
eventual consistency - drift window opens
Query 1: similarity search
external vector DB returns row IDs
Query 2: fetch source rows
second hop back to the object store
2
Search the vector DB, then fetch source rows from the object store.
Eventual - drift
Between ETL runs, vectors and documents disagree - stale or missing rows in results.
The co-location and atomic-consistency advantages are verifiable design facts of storing vectors as a first-class column. The two-step retrieval and drift window are inherent to any architecture that keeps the vector index in a separate store from the source data.
The sync problem with bolt-on vector DBs
Standalone vector databases force a second copy of your data and a pipeline to keep it current. The trade-offs are structural, not incidental:
Pinecone
Proprietary SaaS on fixed pods - capacity comes in discrete steps and you're locked into the platform. The source content lives elsewhere, so retrieval is a two-step hop across the network.
Milvus
RAM- and GPU-memory bound - to scale you must shard the index and broadcast queries (scatter-gather), and metadata stored alongside vectors is thin.
PGVector
Vectors in Postgres are convenient, but inherit Postgres's single-node and sharding limits - fine for millions, painful at billions.
Every one of these keeps the vector index in a separate store from the source data, which is what opens the drift window and forces the second retrieval hop shown above.
How vector search got here
Vector search is a decade of algorithms, each solving the bottleneck of the one before it - exact scans, inverted files, in-RAM graphs, on-disk graphs, managed SaaS - until trillion-scale broke them all. Walk the timeline to see what each design optimized, and the wall it hit.
How vector search got here - a decade of algorithms
Each algorithm solved the problem of the one before it, until scale broke them all. Tap an era to see what it did - and the wall it eventually hit.
VAST Vector
2025 · Hierarchical on DASEWhat it did
A recursive K-means tree on shared-everything NVMe - vectors are a SQL column.
What changed
Removes the constraint: trillions of vectors, no sharding, latency stays flat.
None of the earlier designs was built for trillions of vectors - they each optimized a different constraint. See the scaling wall below for where each one stops.
The scaling wall of shared-nothing vector search
Most vector databases are shared-nothing: each node owns a slice of the index and only its own slice. That is fine until the index stops fitting in one machine's RAM - and memory-resident indexes like HNSW and FAISS are only fast while the entire index lives in memory. At billions of vectors the RAM bill becomes unsustainable, so the index gets sharded across nodes. Sharding doesn't remove the problem, it relocates it: now every query must scatter to every shard and the coordinator must gather and re-rank before answering.
Step through a sharded search below, then flip to VAST's disaggregated shared-everything design. Toggle a shard to overloaded to see the structural weakness: because the coordinator must wait for the slowest shard, one sick or out-of-sync node sets the latency - or fails the query outright - for everyone.
Press Run query to scatter a search across the shards. Toggle a shard to overloaded to see how one slow node stalls the whole query.
Shared-nothing scaling wall
Memory-resident indexes (HNSW, FAISS) are fast only while the whole index fits in RAM. At billions of vectors that RAM bill is unsustainable, so operators shard across nodes - which just shifts the problem to scatter-gather fan-out, index spills, rebalancing, and the risk that one overloaded or out-of-sync shard slows or fails the entire search.
VAST DASE answer
VAST eliminates sharding entirely. Stateless CNodes have lockless, parallel access to one global vector index on shared NVMe, so no node owns a partition and there is nothing to fan out or rebalance. Paired with a hierarchical, distance-clustered index instead of an in-RAM graph, VAST reports sub-200ms search across trillions of vectors.
Latency figures are illustrative to show tail-latency behaviour; sub-200ms at trillion-vector scale and the no-sharding DASE design are VAST-reported.
VAST removes the shards rather than managing them. In its Disaggregated, Shared-Everything (DASE) architecture, stateless CNodes reach all storage over NVMe-oF, so no node owns a partition and there is nothing to fan out, rebalance, or spill. The vector index itself is a hierarchical, distance-clustered tree (not an in-RAM graph) where each level prunes ~1,000× the candidates of the level below, so a query walks top-down and only scans one localized leaf chunk. New vectors land in a fast non-clustered table and are organized by background reclustering, so inserts never freeze the index or disrupt in-flight search. The combined result, VAST reports, is sub-200ms similarity search across trillions of vectors with no sharding and no index freezes.
“Sub-200ms across trillions”, the ~1,000× per-level fan-out, and the no-sharding DASE design are VAST-reported. The scatter-gather and memory-residency limits of shared-nothing indexes are general properties of that architecture.
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 that keeps the tree dense as data flows in - the step from messy, overlapping clusters to clean, well-separated ones.
Holds up to 1,000 vectors.
Top-down recursive search
A query starts at the root and compares against centroids, following only the few closest branches down each level. It never scans the namespace - it resolves the exact nearest neighbours inside one localized L1 leaf chunk. That is logarithmic work, so latency stays predictable as the dataset grows past memory.
Logarithmic growth, no resharding
Adding a level multiplies capacity ~1,000× - L4 reaches a trillion vectors, L5 ~1 quadrillion - without raising the shard count or rearchitecting. There is no shard migration, index freeze, or global rebalance: memory usage stays stable and ingest stays uninterrupted at any scale.
The L0-L5 capacities, ~1,000× per-level fan-out, 10% K-means sample, and reclustering design are from VAST's published vector index; sub-200ms at trillion-vector scale is VAST-reported.
To see why that hierarchy is fast, run a query against it. Generate an index, enable the canvas, then click anywhere to fire a search. Watch the three phases: a coarse scan compares the query against the 12 centroids only, the engine prunes to the single nearest cluster and unloads the rest, then it does an exact scan inside that one chunk. The “work saved” counter is the share of vectors never touched.
0
Total vectors
0
Vectors scanned
0%
Work saved
A 2-D illustration of hierarchical pruning. Real VAST indexes nest five levels (L1-L5) so each level prunes ~1,000× the candidates of the level below; the principle - scan a tiny localized chunk, not the whole dataset - is the same.
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. VAST reports that at 50 billion vectors this delivered roughly 91% lower cost per 1,000 searches than leading sharded systems, at over 1,000 QPS and sub-second latency - the gap coming largely from not having to keep tens of billions of vectors in expensive RAM.
The 50B-vector cost and QPS comparison is VAST-reported. The hierarchy, recursive search, and background-reclustering mechanics are from VAST's published vector index design.
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.
Inside the walk - beam width & the ratio rule
The query carries a beam of the closest centroids down each level, widening it toward the leaves. The ratio rule decides how wide: keep expanding while dist(farthest selected) / dist(closest) < ratio. Tune the ratio and watch the work-vs-recall trade.
Quantized scans (int8)
81.0K
centroids + leaf vectors compared
Full-precision reranks
178
originals fetched at the leaf only
Corpus scanned
8.1e-6%
of 1.0T vectors
~96.2% recall
higher ratio → wider beam → more recall, more scans
The walk only ever touches a vanishing fraction of the corpus, yet the leaf rerank keeps recall high. Admins set the ratio with vsetting; a session can override min_per_level / max_per_level at query time.
Illustrative model on a 1T-vector table (1,000-way branching). Beam bounds and the 1.8 default ratio are VAST-documented; the recall figure is an illustrative proxy.
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 reports roughly 11× the throughput of a leading disk-based shared-nothing system - and where sharded systems can't practically be tested at all (50 billion vectors), VAST sustains over a thousand queries per second on just 8 CNodes. Because tens of billions of vectors no longer have to sit in expensive RAM, the cost per thousand searches drops by about 91%.
VAST Vector Search Benchmark
More than 11x faster at 1 billion vectors (128-dim), at 99% recall - and ~91% lower cost.
~91% lower cost per search vs sharded baseline.
50B vectors on 8 CNodes: 1,026 QPS @ ~317ms (375 threads) · 606 QPS @ ~114ms (75 threads). Milvus was not tested at 50B due to scaling limits.
Figures are VAST-reported. 1B vectors @ 128-dim: ~1,000 QPS vs Milvus 2.6 disk (AISAQ) ~89 QPS at 99% recall; ~$0.003 vs ~$0.033 per 1,000 searches. 50B vectors on 8 CNodes: 1,026 QPS @ ~317ms (375 threads) and 606 QPS @ ~114ms (75 threads). Ingest ~1M vectors/s via Parquet; background clustering ~290K vectors/s.
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 neighbours to a query embedding, filtered to a brand and a price range, without round-tripping between two systems. VAST reports sub-second similarity search at trillion-vector scale.
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, VastDB SDK), which keeps vectors and results in columnar form end to end. That makes semantic search, recommendations, hybrid metadata + vector queries, and time-series vector lookups all the same query shape against one table.
“Sub-second at trillion-vector scale” is a VAST-reported claim. The co-location, atomic-consistency, and index-at-write properties above are verifiable design facts of storing vectors as a first-class column.
GPUs accelerate more than model inference here - they speed up the whole vector pipeline. VAST reports index builds running about 4.5× faster on GPU (hours to minutes) using NVIDIA's cuVS library, and its Sirius GPU-accelerated SQL engine running up to 20× faster than DuckDB on NVIDIA RTX PRO 6000 - all while ingesting on the order of a million vectors per second.
GPUs accelerate the whole vector pipeline - not just inference
VAST puts NVIDIA GPUs to work across ingest, index build, and SQL query - so high-velocity vector search and analytics run end-to-end on the GPU.
NVIDIA CUDA Vector Search - GPU kernels for building & querying ANN indexes.
NVIDIA RTX PRO 6000 hardware that runs the Sirius SQL engine.
VAST's GPU-accelerated SQL engine - up to 20x faster than DuckDB.
Figures VAST-reported: 4.5x GPU index build (10h → 2.5h); Sirius up to 20x vs DuckDB on NVIDIA RTX PRO 6000; ~1M vectors/s ingest on CNode-X (1024-dim); vector search via NVIDIA cuVS.
Where the vectors & index live
Faster memory is smaller and pricier; slower storage is vast and cheap. Classic ANN libraries (HNSW, IVF) assume the whole index fits in the top two tiers - which is exactly what breaks at a billion-plus vectors. VAST keeps the index resident on the shared NVMe pool and prunes small columnar chunks, so search doesn't require petabytes of RAM. Tap a tier.
index lives resident here; CNodes read it over NVMe-oF - no full-RAM copy
Latency figures are order-of-magnitude access-time bands for each media class, not VAST-specific benchmarks.
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.
VAST vs conventional vector-DB techniques
The retrieval tricks teams bolt onto vector DBs - hybrid fusion, filtered ANN, rescoring, diversity, GPU build - and how each collapses into one SQL engine on VAST. Pick a technique.
Combine semantic (vector) and lexical (BM25) signals into one ranking.
Conventional vector DB
Run a vector search and a lexical search separately, then fuse the lists in the app with RRF or DBSF (Qdrant, Weaviate).
VAST approach
Both axes run inside one SQL query; weighted fusion is expressible in SQL - no app-level merge. Default top-1000 candidate pool (vs ~100 on AWS S3 Vectors) gives 10× to rerank over.
Index families, head to head
| HNSW | IVF-PQ | DiskANN | Hierarchical K-means | |
|---|---|---|---|---|
| Index location | RAM (graph + vectors) | RAM (centroids + codes) | SSD graph + small RAM | NVMe flash (vectors + index) |
| Memory cost | ≈4d + 8M B/vec (~91TB at 20B×1024d) | Reduced via PQ, still RAM-bound | Tens of GB RAM | Near-zero per vector (only centroids in RAM) |
| Practical scale | ≈1B / node | ≈1B / node | ≈10B / node | 50B proven · 256T ceiling |
| Ingest cost | Hours-days graph rebuild | Periodic re-quantization | Heavy disk I/O on update | 1k vec/s/CNode + background reclustering |
| Filter / metadata | Post-filter or ACORN | Post-filter | Post-filter | Native SQL push-down (any column) |
| Best for | <1B, high recall | Smaller, compressed | Single-machine 1-10B | Trillion-scale RAG, real-time updates |
Hierarchical K-means is the only index here that scales beyond one node without sharding - and the only one whose memory cost stays flat as the corpus grows. Figures (96-99% recall, 4.5× GPU, top-1000 default, 256T ceiling) are VAST-reported.
What you can configure
The vector column and its index expose a small, typed set of knobs at schema, index, and query level.
Vector dimension
up to 4,096
set at column creation
Distance metric
3 options
cosine · Euclidean · neg. inner product
Top-K
SQL LIMIT
required - no default value
Metadata columns
up to 31,936
typed SQL columns, not flat tags
Secondary sort keys
up to 4
when a secondary index is used
Cluster scan
adaptive or set
ratio default via admin · per-session override
Manhattan distance is not currently supported (under consideration). Configuration details are VAST-documented (5.4 / 5.5).
Hyperscale math: what a billion (or trillion) vectors costs
The reason “just put it all in RAM” stops working is arithmetic. Raw footprint is num_vectors × dimensions × bytes/component. An in-memory graph index like HNSW then adds its links on top, while quantization shrinks the payload instead - VAST's own index uses 8-bit scalar quantization (int8) for the walk, fetching full-precision originals only to rerank the few leaf candidates. Work the numbers yourself, and notice where the total crosses from gigabytes into petabytes - that crossover is exactly why a trillion-vector index can live on NVMe but not in DRAM.
What a billion (or trillion) vectors actually costs
Raw footprint is just num_vectors × dimensions × bytes/component. The index you choose then either piles RAM on top (HNSW) or shrinks the payload (PQ). Drag the controls to watch the total cross from gigabytes into petabytes. Units are decimal (1 GB = 10⁹ B, 1 TB = 10¹² B).
HNSW - recall very high. Graph index - highest recall & speed, but RAM-hungry (graph + raw).
Formula breakdown
= 1.0B × 1536 × 4 B × 1.08
= 1.0B × 32 × 2 × 4 B
1.0B vectors at 1536 dims in FP32 is 6.14 TB of raw payload. HNSW adds a 256.0 GB graph on top - this is the index that must live resident in RAM, so at a billion-plus vectors it is the line item that breaks the memory bank.
The recall ↔ latency ↔ cost triangle. HNSW buys the highest recall and lowest latency by keeping a big graph resident in RAM. IVF and PQ cut that cost - IVF by probing only a few lists, PQ by compressing the vectors themselves - at the price of recall. VAST's hierarchical, NVMe-resident index sidesteps the “whole index must fit in RAM” constraint these in-memory libraries assume.
Estimates use standard rules of thumb: HNSW graph ≈ N × M × 2 × 4 B (M=32) plus ~8% allocator slack on the raw vectors; IVF nlist ≈ √N (capped); PQ m=16, k=256(8-bit codes). Real systems vary with build parameters - treat these as order-of-magnitude, not exact.
What's next: the VAST AI OS
The next VAST AI OS release pushes the vector store further. Its Hyperscale Vector Index replaces flat, memory-resident graphs with the hierarchical, quantized, DASE-persisted index above - so latency plateaus as the dataset grows instead of degrading. The native query engine adds 50+ aggregation functions, and SQL-native partitioning runs queries about 20% faster than Apache Iceberg.
VAST AI OS · New Updates Coming Soon!
Vector Search & SQL Analytics
Hyperscale Vector Index
Hierarchical clustering replaces flat, memory-resident graph indexes (HNSW/FAISS-style) so latency plateaus instead of degrading at scale.
Native Query Engine
50+ new aggregation functions added to the engine, broadening in-place SQL analytics over your data.
SQL-native Partitioning
Partitioning built into the table format delivers ~20% faster queries than Apache Iceberg.
Inside the Hyperscale Vector Index
- Hierarchical clustering - Replaces flat graph structures so search narrows in tiers.
- Quantized clusters - The cluster centroids above L0 are quantized to shrink the index footprint - the L0 vectors themselves stay full-precision.
- Targeted fragment reads - Only the relevant index fragments are read per query.
- DASE persistence - Persisted in disaggregated shared-everything storage, not pinned in RAM.
Query latency as data scales
SQL-native partitioning vs Apache Iceberg
~20% fasterLower query time is better; ~20% reduction relative to Iceberg.
Features from VAST's recent AI OS updates; figures VAST-reported.
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.