Part 2 of 2: How VAST stores vectors as a first-class data type, replaces brute-force indexing with hierarchical clustering to search trillions of vectors in under 200 milliseconds, unifies governance across every data type, and what that means against PGVector, Milvus, and Pinecone.
Part 1 of this series made the case that vector databases are the backbone of enterprise AI, and that the architectures most teams reach for first, a Postgres extension or a sharded, memory-resident engine, start to crack under real scale. They force manual sharding, they hit a memory wall, and they scatter governance across disconnected systems. This post is about the alternative: a vector store that was purpose-built for these workloads rather than adapted from a system designed for a different era.
The VAST Vector Store is integrated natively into the VAST DataBase, and that single design decision changes the economics and the operations of large-scale vector search. By replacing brute-force indexing with a hierarchical clustering approach, it delivers sub-200-millisecond search across trillions of vectors, without sharding, without index freezes, and without the operational chaos that usually comes with them. What follows is how it actually works, how it compares to the alternatives, and the numbers that back it up.
The core idea: vectors as a first-class data type
Conventional vector stores require massive in-memory graph indexes, external stores, and sharding. At billion-scale and beyond, that means operational complexity, high cost, and data duplication, because the vectors live in one place and the data they describe lives somewhere else. The VAST approach starts by removing that separation entirely.
In the VAST DataBase, vectors are stored as a first-class data type, natively, alongside structured data and metadata in the same tables. The VAST Vector Store is not a separate product that you integrate and synchronize. It is part of the VAST DataBase itself, which means a single platform holds your raw content, your structured attributes, and your embeddings together. You define vector columns with fixed dimensions, and the system supports vector similarity search directly against them.
Because the vectors live next to everything else, you can combine vector search with traditional filtering and ordering in one query. That unlocks hybrid search, where vector similarity is combined with conventional filters such as timestamps, categories, or any metadata, in a single request. Built-in distance functions cover the common cases, including Euclidean distance and cosine similarity, and results can be ordered by similarity and limited to the top matches. The same model naturally handles time-series vector data, where vectors carry timestamps for temporal analysis.
The integration story is deliberately practical. The store uses PyArrow for data structures and Arrow tables for efficient data transfer, an ADBC (Arrow Database Connectivity) driver for querying, and the VastDB software development kit for creating tables and inserting data, all organized in a clean hierarchy of buckets, schemas, and tables. The point is that vector search becomes a native database capability rather than a bolt-on, which is what makes everything that follows possible.
The breakthrough: hierarchical clustering instead of brute force
The heart of the system is how it indexes vectors. VAST moved away from a brute-force search methodology, which required scanning the entire dataset for every query. That approach forced a linear amount of work that grew directly with the data, limiting scale and spiking processor usage on the compute nodes. In its place is a Hierarchical Clustering Index, which enables logarithmic search complexity. The difference between linear and logarithmic is the difference between a system that slows down as it grows and one that stays fast.
The idea behind hierarchical clustering is intuitive. Data is organized into a multi-level tree of clusters, where each level groups similar vectors and summarizes them with representative points called centroids. As the collection grows, the system can narrow down search candidates quickly by walking the tree rather than reading everything. It is like organizing a library by sections, then shelves, then books: you find what you need fast, even as the collection expands, because you never have to scan every book.
VAST implements this as a recursive hierarchy of quantized vectors across six levels. Level 0 is a single vector. A Level 1 cluster contains up to 1,000 vectors. A Level 2 cluster contains up to 1,000 Level 1 clusters, which is one million vectors. A Level 3 cluster contains up to 1,000 Level 2 clusters, reaching one billion vectors. Level 4 reaches one trillion vectors, and Level 5 reaches one quintillion. This structure grows logarithmically, which is what lets the system scale from billions to trillions of vectors without rearchitecting and without increasing the shard count, because there are no shards to increase.
Querying follows the structure. When a query arrives, the system starts at the top of the cluster tree and progressively narrows toward the most relevant clusters at each level. Only targeted portions of the index are searched, which avoids both full scans and the global fan-out that makes sharded systems fragile. The result is fast, predictable performance even when the dataset is far larger than memory, because searches traverse a specific path of centroids rather than scanning every vector in the namespace.
How the index stays healthy without freezing
A clustering index is only useful if it stays well-organized as data flows in, and doing that without interrupting live queries is where many systems stumble. VAST handles it with continuous ingest and background reclustering, so the index is maintained without index freezes or global rebalancing.
On ingest, new rows are inserted into a landing table, and the system keeps open higher-level clusters ready to house newly created ones. As a batch of roughly a million new vectors accumulates, it is formed into a new Level 2 cluster of 1,000 Level 1 clusters and placed into an open Level 3 cluster. When a containing cluster fills up, it is closed and a new one is opened, and this happens recursively up the levels as needed. None of it blocks the queries running at the same time.
In the background, a centralized task continuously optimizes the index by selecting clusters that would benefit from reclustering and dispatching jobs that run K-means clustering on them. Reclustering a Level 2 cluster means running K-means on its million vectors to form 1,000 fresh Level 1 clusters; reclustering a higher level does the same one tier up. To keep this efficient, the K-means itself is optimized: it runs on a ten percent sample first to find good starting centroids, then refines across all elements. Candidates for reclustering are chosen using a silhouette score, which measures how well-separated the clusters are, together with the number of elements in a cluster and the need to compact deleted entries. A primary key supports single-vector insert, get, update, and delete with fast access and uniqueness, using locking to avoid duplicate keys.
The deeper point is a change in framing. VAST treats vector search as a progressive narrowing problem inside a distributed database, not as a graph-traversal problem spread across shards. That reframing is what eliminates the shard migrations, index freezes, and global rebalancing that define the day-to-day pain of legacy systems.
The operational benefits follow directly. There is no shard migration, no index freeze, and no global rebalancing to schedule. Continuous ingest and background clustering keep the index current without disrupting queries, which gives operators stable memory usage, uninterrupted ingest, and genuinely simplified management at any scale.
Disaggregated, shared-everything: no shards to coordinate
Underneath the index is an architectural choice that explains a great deal of the performance and simplicity. The VAST DataBase uses a disaggregated, shared-everything model, often abbreviated DASE. All data, the vectors, the metadata, and the raw content, resides in a single, globally accessible space. Every compute node can access the full dataset in parallel.
This is the opposite of the shared-nothing, sharded model described in Part 1, where each node owns a slice and queries must fan out across all of them. With shared-everything, there is nothing to shard and nothing to fan out to, because every node already sees all the data. Scaling out means simply adding compute nodes, with no manual sharding or partitioning, no data migration, and no rebalancing. The effect on performance is that latency stays low and consistent as data grows, instead of climbing as coordination overhead and memory pressure mount. The effect on operations is that scaling becomes automatic and seamless rather than a project.
How it compares to PGVector, Milvus, and Pinecone
When an organization evaluates vector platforms, the conversation almost always includes PGVector, Milvus, and Pinecone. Each has genuine strengths and a real constituency, and each makes a different architectural trade-off that shapes how it behaves at enterprise scale. It is worth being fair and specific about where each one hits its wall.
PGVector adds vector search to PostgreSQL. It is convenient and familiar, but it inherits the scaling and resource limits of its parent database. Scaling requires manual sharding or replication, and performance degrades as indexes outgrow local memory or storage. Running vector and SQL queries together tends to create resource contention, which makes large mixed workloads difficult to support efficiently.
Milvus is purpose-built for vector search and uses memory, with optional GPU acceleration, for speed. But as datasets grow, operators must shard data across nodes, and performance drops when indexes exceed available memory or GPU capacity. Disk-based indexes help, but they are slower than the in-memory path. Milvus also offers only basic support for metadata and structured queries, so richer analytics or document management often require external systems, adding integration and management complexity.
Pinecone delivers vector search as a managed cloud service, which simplifies setup for small teams. It enforces scaling through fixed-size pods, so large datasets must be split and managed across multiple pods, introducing latency, complexity, and the potential for inconsistency at scale. Reliance on external object stores for retrieval, limited hardware choices, and vendor lock-in further constrain control for large organizations.
VAST Vector Store takes the disaggregated, shared-everything path with integrated governance. All data types live in one globally accessible space, which eliminates sharding and silos, every compute node accesses the full dataset in parallel for linear scalability, and governance and security are consistent across all data types. The contrast is clearest when you line the approaches up directly.
| Dimension | PGVector | Milvus | Pinecone | VAST Vector Store |
|---|---|---|---|---|
| Core design | Postgres extension | Native engine, memory/GPU | Managed SaaS, pods | Native in VAST DataBase, DASE |
| Scaling method | Manual sharding/replication | Shard across nodes | Add fixed-size pods | Add compute, no sharding |
| Limit hit at scale | Postgres resource limits | Memory/GPU capacity | Pod boundaries | Scales to trillions linearly |
| Metadata + vectors | Contention in one DB | Basic, often external | External object stores | Unified, one table |
| Governance | Layered on top | Often siloed | Still evolving | Built-in, all data types |
The pattern in that table is the story. PGVector, Milvus, and Pinecone each scale by adding a layer of coordination, whether that is shards, partitions, or pods, and each of those layers becomes the bottleneck as data grows. VAST removes the layer instead of managing it.
Walk through what happens as a dataset expands beyond a single node or memory limit. With PGVector and Milvus, indexes outgrow local RAM or GPU, which triggers sharding or partitioning; with Pinecone, the dataset exceeds a pod’s capacity and requires more pods. With VAST, there is no memory or node limit, because data remains accessible to all compute nodes. Where the others demand manual sharding, partitioning, or pod provisioning, VAST simply adds compute. Where the others require operators to rebalance data, migrate indexes, manage cross-shard queries, or handle two-step retrieval from external stores, VAST needs no manual intervention. And where the others see latency climb as coordination and memory pressure grow or as pod boundaries and network hops accumulate, VAST maintains low, consistent latency regardless of scale.
Governance and security, built in rather than bolted on
Performance and scalability get most of the attention in AI infrastructure conversations, but governance and security are where enterprise deals are actually won or lost. Regulators, security teams, and legal departments all need clear answers before any AI initiative can move forward at scale, and when data is siloed across multiple systems with inconsistent controls, those answers are hard to give. This is the silo problem from Part 1, and the VAST DataBase addresses it by building governance in from the start.
Rather than layering security policies on top of fragmented systems, VAST applies consistent, atomic-level controls across every data type, from raw files to vector embeddings, at every stage of the pipeline. The single most important detail is inheritance: VAST vectors automatically inherit permissions from the source objects they are derived from. That guarantees consistency from raw data all the way to vector, and it eliminates the gaps that an attacker or a simple mistake could exploit, because there is never a moment where the embedding is governed differently from the document it came from.
Around that core idea sits a complete set of enterprise capabilities. Permissions can be set at ingest and apply down to the row and column level, so sensitive information stays controlled even within large, shared datasets. Every data interaction, including queries, searches, and AI operations, is logged into tables with thousands of fine-grained metrics, producing a complete, queryable audit trail for investigations and regulatory audits. Policy changes are enforced in real time across the entire platform, instead of taking hours or requiring manual coordination as they do in legacy systems. And these unified controls extend into RAG and other AI pipelines, so the context a model retrieves is strictly confined to what the user or process is authorized to see, which prevents accidental or malicious data exposure during AI operations.
The lifecycle ties it together. Data is registered the moment it arrives, permissions are applied or inherited at that point, every query triggers a real-time access evaluation, every interaction is logged, and policies are continuously enforced and instantly adapted to change. Security and compliance are built in, not bolted on, which is exactly what lets an enterprise innovate with AI confidently rather than cautiously.
What the numbers show
Architecture is only convincing when it produces results, and this is where the design pays off. At fifty billion vectors, VAST’s hierarchical clustering delivered 91 percent lower cost per 1,000 searches compared to leading sharded systems, while sustaining more than 1,000 queries per second at sub-second latency. In concrete terms, that worked out to roughly $0.003 per 1,000 searches at that scale. Crucially, performance remains stable as data grows, because the logarithmic index does not degrade the way a memory-bound or shard-coordinated system does.
The reason that cost gap is so large is worth naming. Most of the expense in scaling a vector system to fifty billion vectors and beyond comes from the hardware required to keep in-memory indexes resident. By replacing that model with hierarchical clustering inside a disaggregated database, VAST avoids the memory bill entirely, which is what makes large-scale vector deployments practical and cost-effective rather than a budget line that grows faster than the value it delivers.
Translating the architecture into business value
For the teams who have to explain this to a customer or an executive, the technical detail resolves into four pillars, each connecting a differentiator to a concrete outcome.
- Unmatched scalability: handling trillions of vectors and exabytes of data, scaling linearly as needs grow, which future-proofs AI investments and removes the risk of outgrowing the platform or facing a disruptive migration.
- Unified governance and security: a single control plane for structured, unstructured, and vector data, with real-time, atomic-level policy enforcement that reduces risk and audit complexity while keeping the organization compliant.
- Operational simplicity: no sharding, no pipeline sprawl, no manual management, and no external bolt-on vector store, which means lower operational overhead, faster deployment, and more time spent delivering value rather than maintaining infrastructure.
- Real-time AI impact: instant ingest, embedding, and retrieval that powers RAG and semantic search at the speed of business, so organizations can make smarter decisions, respond to change faster, and unlock new revenue streams.
These pillars also answer the objections that come up most often. Yes, many systems claim scalability, but legacy and sharded ones hit memory and coordination bottlenecks; VAST’s shared-everything design scales linearly without sharding. Security is unified and built in rather than fragmented and layered on. The unified platform lowers total cost of ownership and accelerates return on investment by eliminating multiple databases and complex pipelines. And the architecture is designed for the next generation of AI, adapting as data and AI needs evolve so the investment keeps its relevance.
The simplest way to say it: with the VAST Vector Store you can run and automate your AI embedding and RAG pipelines on the same platform that holds your data, governed by the same policies, at trillion-vector scale. That is the difference between bolting AI onto your data estate and building it in.
Bringing the series together
Part 1 showed why vector databases became the backbone of enterprise AI, and why the architectures most teams start with, a Postgres extension or a sharded, memory-resident engine, crack under the scale, speed, and governance demands of real workloads. This post showed the alternative. By storing vectors as a first-class data type in the VAST DataBase, replacing brute-force indexing with a hierarchical clustering index that searches logarithmically, scaling on a disaggregated shared-everything architecture with no shards to coordinate, and unifying governance across every data type, the VAST Vector Store delivers sub-200-millisecond search across trillions of vectors at a fraction of the cost of sharded alternatives.
The recurring theme across both posts is that architecture is destiny. A system adapted from a different era carries the cost of that adaptation into every query and every audit, while a system designed for AI from the ground up makes scale, simplicity, and governance reinforce each other rather than compete. For any organization serious about putting AI into production and keeping it there as data grows, that distinction is not a detail. It is the decision.
Related reading: explore the platform underneath in Inside the VAST DataBase Engine, and see how vector search powers retrieval in From Lakehouse to AI on the VAST DataBase.
The VAST
VAST Vector Store series hub — full series index
Vector Store seriesThis article is part of a two-part series on enterprise vector search in the VAST DataBase. Continue reading:
- Part 1: Why Enterprise AI Needs a New Kind of Vector Database
- Part 2: Inside the VAST Vector Store: Trillion-Scale Vector Search (you are here)