What Is a Vector Database?

The technique it relies on has these dates:

• 30 March 2016: Yu. A. Malkov and D. A. Yashunin publish HNSW on arXiv, a layered graph index for approximate nearest neighbour search.
• 28 February 2017: Jeff Johnson, Matthijs Douze and Hervé Jégou publish "Billion-scale similarity search with GPUs". In March, Facebook releases the Faiss library and writes that traditional databases queried with SQL are not adapted to these vectors.
• 20 April 2021: first release of pgvector, an extension that adds vector search to PostgreSQL.
• 28 August 2023: pgvector 0.5.0 adds the HNSW index type.
• 16 January 2024: the paper "The Faiss library" calls vector similarity search "a core functionality of vector databases".
• 30 October 2024: pgvector 0.8.0 adds iterative index scans, aimed at queries with filters.

On the write path, documents are split into chunks, an embedding model turns each chunk into a vector, and the database stores that vector with the text, or a reference to it, and its metadata. On the read path, the query goes through the same model and the database returns the k nearest vectors. Weaviate stresses that data and queries must use the same model and configuration, because only then are the vectors comparable.

Comparing the query with every stored vector gives the exact answer, but the work grows with the number of vectors and their dimensions. That is why systems use approximate nearest neighbour (ANN) indexes. HNSW builds several layers of proximity graphs and starts each search at the top layer. IVF splits the vectors into lists and only scans the lists closest to the query; according to the pgvector documentation, it builds faster and uses less memory than HNSW but has a worse speed-recall trade-off. Quantization compresses the vectors to save memory, usually at some cost in precision.

Which distance metric fits (cosine, Euclidean distance or dot product) depends on the embedding model. How similarity is measured is covered in the entry on embeddings.

Metadata filters run before or after the vector search. According to Pinecone, pre-filtering narrows the search space, post-filtering considers all relevant results, and both can slow a query down. Weaviate, MongoDB and pgvector also combine vector search with keyword search (hybrid search), which helps with product names, error codes and acronyms.

Approximate search buys speed with recall: it can miss some of the true nearest neighbours. The pgvector documentation warns that once an approximate index is added, the same queries can return different results.

Weaviate sorts tools that offer vector search into three categories:

Source: Weaviate, "What Is a Vector Database?", section "Tool Landscape around Vector Databases"; examples in the second row from the pgvector, MongoDB and Elastic documentation (accessed 14.11.2026).

Faiss is one example of a library. Its project page describes it as a library for efficient similarity search and clustering of dense vectors, written in C++ with Python wrappers and developed primarily at Meta's Fundamental AI Research group; according to the repository, it searches sets of vectors of any size, including ones that may not fit in RAM. The authors' 2024 paper draws the line: Faiss is not a service, because its functions run inside the calling process, and it "is not a database", because it provides no concurrent write access, load balancing, sharding, transaction management or query optimization. The same paper says Milvus relies on Faiss as one of its core engines and Pinecone initially relied on it before rewriting its engine in Rust.

Databases can be run on in-house servers or bought as a managed service. Pinecone is offered as a managed service; Chroma, Milvus, Qdrant and Weaviate publish their code and also run a cloud version.

Uses described by Weaviate, Elastic and MongoDB in their documentation:

• Retrieving document chunks for a language model in RAG.
• Semantic search in a shop catalogue or a help centre.
• Recommending products or content similar to what a person has already viewed.
• Detecting duplicates and near-duplicates.
• Searching images, audio or video by similarity.

Weaviate documents a support assistant that has to explain how to rotate an API key without interrupting an application. The product documentation is stored as small chunks, each with its vector and metadata such as product version and access level. Vector search finds chunks about changing credentials even when they use different wording, keyword search keeps exact matches for "API key", and a filter restricts results to the customer's product version and the documents they may see. Only the top-ranked chunks go to the language model, with instructions to answer from them and cite the source.

An example in the pgvector documentation shows what a filter does behind an approximate index. The HNSW search keeps a candidate list of 40 entries by default (the hnsw.ef_search setting), and the filter is applied afterwards. If the condition matches 10 % of rows, only 4 rows are left on average. Since version 0.8.0, iterative index scans keep reading the index until enough results are found.

According to Weaviate, a separate vector database pays off when similarity search is central to the product and there are production requirements: frequent updates, metadata or permission filters, many concurrent users, low latency, high availability or large datasets.

A separate system may not be needed if the data is small and rarely changes, if search runs offline, or if the current database already meets the requirements. Elastic recommends exact, brute-force kNN without an approximate index for small datasets, and pgvector performs exact search until an index is created. With pgvector, vectors are stored with the rest of the data and keep PostgreSQL's ACID transactions and JOINs.

Weaviate sums up the trade-off: keeping vector search in the existing database simplifies operations and consistency, while a purpose-built system can offer deeper retrieval features or more predictable performance when vector search is the main workload.

Source: Weaviate, "What Is a Vector Database?", comparisons with relational and graph databases; MongoDB, "MongoDB Vector Search Overview", "red fruit" example; pgvector, PostgreSQL features (accessed 14.11.2026).

The line between vector and relational databases has moved, because PostgreSQL, MongoDB and Elasticsearch now search vectors too. According to Weaviate, a purpose-built system stands out through specialised indexing, filtering, multi-tenancy, compression and distributed scaling.

"Vector store" is, according to Weaviate, a broader term that AI frameworks use for the interface to any vector retrieval backend; "vector database" usually implies a complete system with persistence, filtering, security and scaling. Neither term is standardised.

Products and projects with vector search, in alphabetical order, not ranked.

Source: each vendor's product pages, repositories and documentation (accessed 14.11.2026).

Recall figures published by vendors are their own. Weaviate writes that in its internal testing, 8-bit rotational quantization (RQ) retained roughly 98 to 99 % recall with up to 4x compression, and asks readers to measure it on their own data.

A similar text is not a correct answer. Weaviate concedes that a vector database does not by itself prevent a language model from hallucinating. Why embeddings handle negation poorly is explained in the entry on embeddings.

The categories overlap: Weaviate presents its own as tendencies, "not guarantees", with boundaries that are "increasingly blurred". Pinecone, which sells a vector database, argues that standalone indexes, naming FAISS, lack capabilities of any database and may need a full re-index to take in new data. The Faiss paper qualifies this: its API removes and updates vectors by id, but its HNSW index does not support removal or changes, and IVF and PQ indexes lose efficiency when the data distribution shifts significantly. Faiss also stores no metadata; it filters with a callback that receives each vector's id.

Switching embedding models means recomputing every vector. And when several tenants share one approximate index, pgvector notes that one tenant's vectors can affect recall and speed for the others.

• Check whether the database you already use offers vector search.
• Choose the embedding model and record the model and its configuration with the data.
• Split documents into chunks and store each vector with its text and metadata.
• Start with exact search while the collection is small, and add an approximate index when latency calls for it.
• Measure recall on real questions by comparing approximate results with exact ones.
• Plan how you will regenerate every vector before you switch models.

• Combine vector and keyword search where product names, codes or acronyms matter.
• Use the distance metric the embedding model's provider recommends.
• Isolate tenants with partitions or separate tables instead of sharing one approximate index.

• Mixing vectors from different models in the same index.
• Filtering behind an approximate index without checking how many results remain.
• Accepting a vendor's performance figure without measuring it on your own data.
• Treating similarity between texts as proof that an answer is correct.

This entry was written in November 2026 with the help of AI. The information comes from the HNSW and Faiss papers on arXiv, the 2017 Faiss announcement, the pgvector repository, and vendor documentation and product pages. It was reviewed before publication and contains no client data.