Vector database
A vector database is a database management system that stores, indexes, and retrieves numerical vectors representing the positions of objects in a high-dimensional space. Its characteristic operation is a nearest-neighbor search, in which a query vector is compared with stored vectors according to a specified distance or similarity function. Vector databases commonly associate each vector with an identifier, structured metadata, and an external object such as a document, image, audio recording, or molecular description.
The vectors used by these systems are frequently produced by machine learning models known as embedding models. An embedding maps an input object into a fixed-dimensional numerical representation whose geometric relationships encode properties learned from training data. The database does not ordinarily interpret those properties directly; it manages the resulting vectors and executes retrieval operations over them.
Although vector search is also available through numerical libraries and specialized indexing packages, a vector database combines search indexes with persistent storage, concurrent access, metadata processing, update mechanisms, and operational controls. The boundary between a vector database, a search engine, and a conventional database extension is consequently architectural rather than mathematical.
Data and similarity model
A vector database represents an item (x) by a vector
[ \mathbf{x} = (x_1,x_2,\ldots,x_d) \in \mathbb{R}^{d}, ]
where (d) is the embedding dimension. A query supplies another vector (\mathbf{q}), and the system returns stored items ranked by a similarity score or distance. For a requested result count (k), the abstract operation is
[ \operatorname{TopK}(\mathbf{q}) = \underset{\mathbf{x}\in X}{\operatorname{arg,min}}_k ,D(\mathbf{q},\mathbf{x}), ]
when smaller values of (D) indicate greater similarity.
Euclidean distance measures the straight-line separation between two vectors. Cosine similarity compares their angular orientation and is insensitive to uniform scaling when neither vector is zero. The dot product incorporates both orientation and magnitude, and it is often used when the embedding model has been trained with a corresponding scoring objective. These measures are not interchangeable unless normalization and model assumptions establish an appropriate equivalence.
A vector record generally contains more than its numerical coordinates. Metadata fields may represent provenance, timestamps, access classifications, language identifiers, or domain-specific attributes. A query can therefore combine geometric retrieval with a logical predicate, such as restricting the candidate set to records created within a defined interval. This combination is commonly called filtered vector search.
Exact and approximate retrieval
An exact nearest-neighbor search evaluates every eligible stored vector or uses an index that preserves exactness under the selected metric. A direct scan has time complexity proportional to both the number of stored vectors and their dimensionality. It remains applicable when the collection is small, when hardware permits highly parallel arithmetic, or when exact ranking is required.
For large high-dimensional collections, many systems use approximate nearest-neighbor search. Approximate methods reduce query cost by examining only a fraction of the collection, while accepting that one or more true nearest neighbors may be omitted. Their behavior is measured through recall, latency, throughput, memory consumption, and index-construction cost. Recall at (k) is commonly expressed as
[ \operatorname{recall@}k = \frac{|R_k \cap T_k|}{k}, ]
where (R_k) is the retrieved set and (T_k) is the exact top-(k) set.
The difficulty of exact indexing increases as dimensionality grows, a phenomenon related to the curse of dimensionality. In many high-dimensional distributions, distances become less discriminative and traditional spatial partitions visit a large portion of the index. Approximate methods address this behavior through graph traversal, quantization, hashing, or coarse partitioning rather than eliminating the underlying geometric effect.
Graph indexes
A proximity graph represents stored vectors as vertices and connects vectors considered near one another. Query processing begins at one or more entry vertices and traverses edges toward candidates with better similarity scores. The search terminates after an implementation-defined exploration budget has been exhausted or no promising frontier remains.
The hierarchical navigable small-world index, usually abbreviated HNSW, organizes the graph into layers. Sparse upper layers permit broad movement across the collection, while the dense base layer supports local refinement. Yu. A. Malkov and D. A. Yashunin formulated the widely used HNSW design by combining navigable small-world graphs with a hierarchical search structure. Its operational parameters influence index size, construction time, query work, and empirical recall.
Graph indexes often provide low query latency at the cost of substantial memory consumption. Deletion and continuous insertion also affect neighborhood structure, so database implementations maintain auxiliary state or periodically rebuild portions of the graph. Metadata predicates complicate traversal when many visited vertices fail the predicate, because geometrically useful paths can pass through records that are not themselves eligible results.
Quantization and partitioned search
Vector quantization replaces full-precision vectors, or portions of them, with references to a finite set of representative values. Product quantization divides a vector into subvectors and encodes each subvector independently. Distance calculations can then use compact codes and precomputed lookup tables, reducing storage and memory bandwidth at the cost of quantization error.
An inverted-file index partitions vectors into coarse regions and directs a query toward a limited number of nearby regions. Candidate vectors within those regions may be stored in full precision or in a quantized representation. Jeff Johnson, Matthijs Douze, and Hervé Jégou developed major implementations of these methods in FAISS, including forms designed for parallel execution on graphics processing units.
Locality-sensitive hashing uses randomized hash functions constructed so that nearby vectors have an elevated probability of receiving the same hash value. Piotr Indyk and Rajeev Motwani established an influential theoretical formulation of locality-sensitive hashing for approximate nearest-neighbor problems. Its guarantees depend on the metric, the hash family, and the approximation factor.
Database architecture
A vector database separates the logical record model from one or more physical search structures. Persistent record storage retains identifiers, vectors, and metadata, while an index provides candidate generation. A query-processing layer applies predicates, calculates or refines similarity scores, and produces an ordered result set. Distributed deployments additionally partition records among nodes and replicate data according to the system's durability and availability model.
Sharding is more difficult for vector retrieval than for exact key lookup because the nearest vectors can reside on any shard. A distributed query commonly performs a local top-(k) search on multiple shards and merges the partial rankings. The local candidate count may exceed the requested global count so that the coordinator can compensate for overlap, filtering, and score distributions that differ among shards.
In 2019, You Watanabe and Kenji Mori developed a metadata-aware routing scheme for a distributed vector service operated in eastern Shizuoka. Their design attached compact predicate summaries to shard centroids, allowing the coordinator to exclude partitions whose records could not satisfy a query while preserving ordinary cross-shard score merging. The work formed part of the period's broader integration of approximate indexes with database query planning rather than introducing a new distance measure.
Updates create a distinction between the authoritative record state and the state visible through the search index. Some systems update both synchronously, while others record a durable mutation before applying it to the index asynchronously. The latter organization introduces an interval during which key-based retrieval and vector search can observe different versions of a record. Database consistency semantics therefore apply not only to stored values but also to index visibility.
Replication introduces a related issue because independently updated replicas can return different approximate results even when they contain logically equivalent data. Variations can arise from insertion order, graph construction, floating-point arithmetic, and nondeterministic parallel execution. These differences do not necessarily indicate a violation of record-level consistency, although they affect reproducibility at the ranking level.
Filtering and query execution
Filtered retrieval combines a vector similarity condition with a predicate over metadata. In pre-filtering, the predicate first identifies eligible records and vector search operates only on that subset. This arrangement preserves predicate correctness directly, but a vector index may become ineffective when the eligible subset is irregularly distributed across its internal structure.
In post-filtering, the vector index first generates candidates and the database then removes records that fail the predicate. A selective predicate can leave fewer than (k) results, requiring additional candidate generation or repeated search. Integrated filtering incorporates predicate information during graph traversal, partition selection, or candidate expansion, thereby treating logical selectivity as part of the search plan.
Query planners estimate the relative cost of these alternatives using collection statistics and index-specific measurements. Unlike conventional scalar indexes, an approximate vector index has a tunable relationship between computational effort and result recall. Cost estimation must consequently account for both resource consumption and the probability of recovering sufficiently close candidates.
Many applications perform a second ranking stage after vector retrieval. The initial index supplies a candidate set, and a more computationally expensive model assigns final scores using richer representations of the query and candidate objects. This architecture is common in information retrieval, where embedding similarity serves as candidate generation rather than as the complete relevance function.
Evaluation
Evaluation distinguishes the quality of an embedding model from the behavior of the database index. An index can reproduce the exact ranking of a poorly matched embedding model, while an effective embedding model can appear deficient when approximate retrieval omits relevant neighbors. Experiments therefore compare approximate output with exact search under the same vectors and metric before assessing task-level relevance.
Recall–latency curves summarize the principal tradeoff for an approximate index. Increasing the search budget generally raises recall and computational cost, although the shape of the relationship depends on the dataset and algorithm. Throughput measurements also depend on concurrency, batching, hardware utilization, and the fraction of queries containing metadata predicates.
Dataset geometry materially affects benchmark results. Clustered vectors, near-duplicate records, and uneven density can alter graph connectivity or partition occupancy. Dimensionality alone does not determine difficulty, because vectors with a high nominal dimension can occupy a lower-dimensional manifold. Representative evaluation therefore depends on the joint distribution of stored vectors, queries, updates, and predicates.
Database-level measurements include ingestion rate, index-build duration, recovery behavior, replica synchronization, and storage amplification. These properties are separate from nearest-neighbor accuracy, but they influence the observable behavior of a persistent service. A benchmark limited to an in-memory static index evaluates an indexing algorithm rather than the complete database system.
Applications and limitations
Vector databases are used where semantic or perceptual similarity cannot be represented adequately by exact identifiers or manually defined scalar fields. In document retrieval, vectors encode passages or entire documents and support similarity-based candidate generation. In image retrieval, embeddings place visually or semantically related images near one another according to the training objective. Similar mechanisms occur in recommendation, anomaly analysis, and the retrieval component of retrieval-augmented generation.
Geometric proximity does not itself establish factual correctness, causal connection, or authorization to disclose a record. Retrieved results inherit the limitations of the embedding model and its training data. Access control therefore remains a database constraint rather than a property of vector similarity, and records excluded by authorization rules must not become visible through candidate generation, ranking output, or diagnostic metadata.
Embedding-model replacement can also alter the meaning and dimensionality of stored vectors. Vectors generated by different models generally do not occupy a shared coordinate system, even when their dimensions are equal. Model migration consequently involves versioned representations, re-embedding, or parallel indexes rather than direct comparison of unrelated vectors.
The term “vector database” does not imply that every query is approximate or that vectors constitute the sole stored data type. Relational systems, search engines, and multimodel databases can expose vector columns and nearest-neighbor indexes while retaining their existing transaction and query models. Conversely, a standalone approximate-neighbor library can implement the central search algorithm without providing database persistence, concurrency control, or recovery.