What is a vector database?
A vector database stores embeddings, lists of numbers that represent meaning, and quickly finds the stored vectors most similar to a query vector. It is the search engine behind semantic search and most RAG systems. Examples include Pinecone, Weaviate, Qdrant and Milvus, and many general databases such as Postgres with pgvector now offer vector search too.
A vector database answers one question very fast: which stored items mean something closest to this? Everything else it does, from filtering to replication, supports that.
How does a vector database work?
A vector database stores each item as an embedding along with its original text and metadata. At query time, the query is embedded with the same model, and the database returns the stored vectors with the highest similarity, usually by cosine similarity or dot product, together with their text.
Comparing the query with every stored vector, called exact or brute-force search, is simple and accurate but slows down as the collection grows into the millions. So vector databases use approximate nearest neighbour (ANN) indexes, which find almost all of the true nearest neighbours while checking only a small fraction of the vectors.
What is HNSW?
HNSW (Hierarchical Navigable Small World) is the most widely used ANN index. Described by Malkov and Yashunin in 2016, it builds a layered graph: each vector is connected to some of its close neighbours, and upper layers hold fewer vectors with longer links, like express lanes. A search starts at the top, jumps quickly toward the right region, then walks down through denser layers to find the closest matches.
| Index type | How it works | Trade-off |
|---|---|---|
| Flat (exact) | Compares with every vector | Perfect recall, slow at large scale |
| HNSW | Layered neighbour graph | Fast and accurate; uses more memory |
| IVF | Clusters vectors, searches only the nearest clusters | Less memory; recall depends on how many clusters are searched |
| Quantisation (PQ, binary) | Compresses vectors to fewer bits | Much less memory; some loss in accuracy |
Most indexes have settings that trade speed for recall. Measure recall on your own queries, not only speed.
What features matter in a vector database?
- Metadata filtering
- Restrict results by fields such as user, date or document type, essential for access control
- Hybrid search
- Combine vector similarity with keyword search in one query; see hybrid search
- Upserts and deletes
- Update or remove vectors when documents change, without rebuilding the index
- Namespaces or collections
- Keep separate indexes per customer or per project
- Recall tuning
- Settings that trade search speed for finding more of the true matches
Do you need a dedicated vector database?
Often not at first. If you already run Postgres, the pgvector extension adds vector columns and HNSW or IVF indexes, and keeps vectors next to the rest of your data with normal SQL filtering and transactions. Search engines such as Elasticsearch and OpenSearch, and many cloud databases, also support vector search. For prototypes, an in-memory library such as FAISS, open-sourced by Meta, is enough.
| Option | Good fit |
|---|---|
| In-memory library (FAISS, NumPy) | Prototypes and small, static collections |
| Postgres with pgvector | Apps already on Postgres, up to many millions of vectors with good tuning |
| Search engine with vectors (Elasticsearch, OpenSearch) | Teams that already run one and want keyword plus vector search |
| Dedicated vector database (Pinecone, Weaviate, Qdrant, Milvus) | Very large collections, high query volume, or advanced vector features |
What are common vector database mistakes?
- Do: Store the source text, title and URL with each vector, so results can be shown and cited
- Do: Filter by permissions in the query, not after retrieving results
- Do: Record which embedding model produced each vector
- Avoid: Mix vectors from different embedding models in one index
- Avoid: Judge search quality by speed alone without measuring recall on real queries
- Avoid: Assume better vector search fixes bad chunking; it cannot find a passage that was split badly
Frequently asked questions
What is a vector database used for?
Vector databases power semantic search, retrieval for RAG, recommendations, deduplication and clustering, anywhere software needs to find items similar in meaning rather than matching exact words.
Is pgvector good enough for production?
For many applications, yes. pgvector supports HNSW indexes and scales to millions of vectors with tuning. Dedicated vector databases can be easier at very large scale or very high query rates.
What is the difference between a vector database and a regular database?
A regular database finds rows by exact values and ranges. A vector database finds items by similarity between high-dimensional vectors, using specialised approximate nearest neighbour indexes.
What is approximate nearest neighbour search?
It is a family of methods that find nearly all of the closest vectors to a query while checking only a small part of the collection, trading a little accuracy for large speed gains.
Last checked for accuracy on . Written by the solidcoder team.