A vector database is a database built to store and search high-dimensional vectors — the numeric embeddings that represent the meaning of text, images…
Understand that a vector database stores embeddings — meaning turned into coordinates.
A vector database stores embeddings: fixed-length lists of numbers produced by a model, where each item — a sentence, a document chunk, an image — becomes one vector, often with hundreds to a couple of thousand dimensions.
The key property is that similar meanings land near each other in this space. 'How do I reset my password' and 'account recovery steps' produce vectors that are close together, even though they share no words. The database's job is to store these vectors and find the closest ones quickly.
Each record usually holds the vector plus the original text (or a reference to it) and metadata like source, author, or date. Metadata lets you filter — 'nearest chunks, but only from 2024 docs' — combining semantic search with ordinary constraints.
See how a query becomes a vector and the database ranks items by distance.
Search runs in three steps. The query text is embedded with the same model used for the stored items, so it lives in the same space. The database then computes a similarity or distance between the query vector and candidate vectors, and returns the top-k closest as results.
Using the same embedding model for indexing and querying is essential — vectors from different models are not comparable.
Three metrics dominate. Cosine similarity compares direction and ignores magnitude, which suits normalized text embeddings. Dot product rewards both alignment and magnitude. Euclidean (L2) distance measures straight-line gap.
For most text-embedding models the vectors are normalized, so cosine similarity and dot product rank results identically. Pick the metric your embedding model was trained for.
Learn why exact search is too slow and how ANN indexes keep queries fast.
The obvious approach — compare the query to every stored vector — is exact but linear: with 10 million vectors, every query scans all 10 million. That is fine for thousands of items and far too slow for production scale.
Approximate nearest neighbor (ANN) search fixes this by building an index that reaches the closest vectors while examining only a small fraction of them, accepting a tiny chance of missing a true neighbor in exchange for large speedups.
Two indexes are common. HNSW builds a layered graph of vectors linked to their neighbors; a query hops through the graph, descending layers, to home in on nearest points in logarithmic-like time. IVF partitions vectors into clusters and searches only the few clusters nearest the query.
Both expose knobs that trade recall for speed — for HNSW, how many links per node and how wide to search; for IVF, how many clusters to probe.
Insert a few vectors and run a nearest-neighbor query to make the flow tangible.
# each text -> vector with the SAME model used at query time for text in docs: db.add(id=text.id, vector=embed(text), metadata={"src": text.src}) q = embed("how do I reset my password") hits = db.query(vector=q, top_k=3, metric="cosine") for h in hits: print(h.id, round(h.score, 3), h.metadata["src"])
Indexing embeds every document and stores the vector with metadata. At query time the question is embedded the same way, the database returns the three closest vectors by cosine similarity, and each hit carries its score and source so you can rank, filter, and cite.
Decide when a dedicated vector database earns its place over simpler options.
Use a vector database when you need semantic search over a large, growing corpus — millions of chunks, frequent updates, metadata filtering, and low-latency top-k queries. It handles the ANN indexing, persistence, and filtering you would otherwise build yourself.
For a few thousand vectors, a simple in-memory search or a Postgres extension like pgvector is often enough and less to operate. Match the tool to the scale rather than reaching for a dedicated database by default.
A vector database complements, not replaces, your primary store. Keep the source of truth where it belongs and use the vector store for semantic retrieval, syncing embeddings as your data changes.
A vector database stores embeddings — meaning turned into coordinates — and finds items whose vectors are closest to a query's. Search embeds the query with the same model and ranks by a metric like cosine similarity, while an approximate nearest neighbor index such as HNSW or IVF keeps that fast across millions of vectors. Use one for large-scale semantic search; lean on pgvector or in-memory search when small.
Imagine building search over 2 million support articles. Choose an embedding model, a distance metric, and an ANN index, and describe one metadata filter you would add — then justify why a dedicated vector database beats scanning every vector for each query.
What is a vector database?
A vector database stores embeddings and specializes in nearest-neighbor search by similarity, not exact keyword matching.
How does similarity search work in a vector database?
Search embeds the query into the same space and returns the nearest vectors by a distance metric; using the same embedding model for both sides is required.
What is an approximate nearest neighbor (ANN) index?
ANN indexes avoid exhaustive scans; HNSW navigates a neighbor graph and IVF probes a few clusters, keeping queries fast at scale.
When should I use a vector database?
A dedicated vector database pays off at scale; for a few thousand vectors, lighter options like pgvector are simpler and sufficient, and it complements rather than replaces your primary store.