A vector database is a database system designed to store, index, search, and manage numerical vectors, particularly embeddings, while often retaining associated metadata and source content. Its main purpose is to support similarity search: given a query vector, the system finds stored vectors that are mathematically close according to a specified similarity or distance measure. This capability is useful for semantic search, recommendation systems, image retrieval, duplicate detection, anomaly analysis, and retrieval-augmented generation. Unlike a traditional relational query that might search for an exact value or match a condition, vector search is generally concerned with approximate or nearest-neighbour relationships in a high-dimensional space.
A typical vector database record contains an identifier, an embedding vector, metadata, and sometimes the original text or another payload. The embedding represents the semantic or task-specific properties learned by an upstream model. Metadata might include document title, author, publication date, access permissions, category, source URL, customer identifier, or other filtering attributes. When a query arrives, the application generates a compatible query embedding and submits it to the vector database. The database then searches its vector index and returns the nearest candidates, often together with similarity scores and stored metadata.
Efficient vector search commonly relies on approximate nearest-neighbour algorithms because exact comparison against every stored vector becomes expensive at large scale. Techniques include hierarchical navigable small-world graphs, commonly known as HNSW, inverted-file approaches, product quantisation, and other specialised indexing methods. Approximate search trades some degree of exactness for substantially improved speed or memory efficiency. Index configuration can influence recall, latency, memory consumption, and construction time. The best configuration depends on dataset size, vector dimensionality, query volume, latency requirements, and acceptable retrieval error.
Similarity metrics are an important part of vector search. Cosine similarity compares the angle between vectors and is often used for embeddings where direction represents similarity. Dot product measures the sum of coordinate-wise products and can behave similarly to cosine similarity when vectors are normalised. Euclidean distance measures geometric distance directly. These metrics are not interchangeable in every application. The embedding model's training objective and documentation generally indicate which similarity function is appropriate. Using a metric inconsistent with the embedding model's intended geometry can reduce retrieval quality.
Vector databases often support hybrid retrieval because vector similarity alone may be insufficient. Hybrid search can combine semantic vector retrieval with lexical methods such as BM25 or exact keyword matching. This is useful for queries involving exact identifiers, product codes, names, error messages, legal terminology, or other strings where lexical precision matters. Metadata filtering can also constrain vector search to authorised or relevant records. A sophisticated retrieval system may therefore combine vector similarity, keyword relevance, metadata filters, reranking, and business rules rather than relying exclusively on nearest-neighbour distance.
Vector databases differ from ordinary relational databases in their primary search model, but they are not necessarily replacements for relational or document databases. An application may store authoritative transactional data in PostgreSQL or another relational system while maintaining embeddings in a vector index. Some established database systems have added vector-search capabilities, allowing structured and vector data to coexist. Dedicated vector databases can provide specialised indexing and operational features, while general-purpose databases may simplify architecture when vector search is only one requirement. The appropriate choice depends on scale, query patterns, consistency requirements, operational constraints, and existing infrastructure.
In RAG, the vector database commonly acts as the retrieval layer between a user's question and a generative model. Documents are first divided into chunks, embedded, indexed, and associated with metadata. At query time, the user's question is embedded, similar chunks are retrieved, and the selected content is inserted into the model's context. Retrieval quality directly affects the quality of the resulting answer. A vector database therefore does not itself generate answers or understand documents in the same manner as a language model; it performs efficient storage and retrieval of vector representations and associated information.
Vector databases have limitations. Similarity search can return semantically related but factually inappropriate results, and embedding quality places an upper bound on retrieval quality. Index approximations can reduce recall, while poor chunking, stale data, duplicate documents, missing metadata, or incorrect access controls can cause serious application-level problems. Vector stores also require lifecycle management: embeddings may need to be regenerated when the embedding model changes, records need updating when source documents change, and deleted or restricted information must be removed appropriately. Effective vector search therefore requires coordinated data preparation, embedding management, indexing, evaluation, security, and application logic rather than treating the database as a standalone solution to information retrieval.
