Quick answer: A vector database is a database built to store and search embeddings, which are numeric representations of text, images, or other data. Instead of matching exact keywords, it finds items whose vectors are closest in meaning using approximate nearest neighbor search. This is what lets a RAG system pull the most relevant passages for a question, and for smaller projects a regular database with a vector extension like pgvector often does the job.
What a Vector Database Stores
Traditional databases store rows and columns, and you query them with exact matches: find the user where email equals this string. A vector database stores something different: high-dimensional vectors, usually a few hundred to a couple thousand numbers each.
Those numbers come from an embedding model. When you embed a sentence, the model turns it into a vector that captures its meaning. Sentences that mean similar things end up with vectors that sit close together in that high-dimensional space, even if they share no words. "How do I reset my password" and "I forgot my login credentials" land near each other despite zero overlapping keywords.
If embeddings are new to you, our guide on what vector embeddings are walks through how text becomes numbers. The one-line version: an embedding is a coordinate for meaning, and a vector database is the store that lets you search by those coordinates.
Alongside each vector, a vector database also holds the original content and metadata: the source text, a document ID, a URL, tags, timestamps. That metadata matters, because in practice you filter on it (only search this customer's docs, only pages from this year) as well as search by similarity.
How Similarity Search Works
The core operation is: given a query vector, find the stored vectors closest to it. Closeness is measured with a distance metric, usually cosine similarity or Euclidean distance.
The naive way is to compare the query against every stored vector and sort by distance. That is called exact or brute-force search, and it works fine for a few thousand vectors. It falls apart at scale, because comparing against millions of vectors on every query is slow.
This is where approximate nearest neighbor (ANN) search comes in. ANN trades a tiny bit of accuracy for a massive speedup. Instead of checking every vector, it uses a clever index to check only a promising subset and still returns almost always the right neighbors.
The most common ANN index is HNSW (Hierarchical Navigable Small World). Conceptually, HNSW builds a layered graph where each vector connects to its near neighbors. A search starts at the top layer, hops toward the query through a few well-connected nodes, then drops into denser layers to refine. It is like finding a house by taking the highway to the right city, then main roads to the neighborhood, then side streets to the door, instead of walking past every house in the country.
The tradeoff worth knowing: ANN is not guaranteed to be perfect. You tune parameters to balance speed, memory, and recall (how often it finds the true nearest neighbors). For most applications a well-tuned index returns the right results well above 95 percent of the time while being orders of magnitude faster than brute force.
Why RAG Needs a Vector Database
Retrieval-augmented generation (RAG) works by fetching relevant context and putting it in the model's prompt. The retrieval step is a search problem: out of thousands or millions of chunks, which handful is most relevant to this question?
Keyword search alone is brittle here. A user rarely phrases a question using the same words as your documentation. Vector search solves that by matching on meaning, so a question about "trouble signing in" surfaces a doc titled "authentication errors" even with no shared words.
A typical RAG retrieval flow looks like this:
# 1. Embed the user's question
query_vector = embed("How do I cancel my subscription?")
# 2. Search the vector database for the closest chunks
results = index.query(
vector=query_vector,
top_k=5,
filter={"source": "help_center"}
)
# 3. Put the retrieved text into the prompt
context = "\n\n".join(r.text for r in results)
answer = llm(f"Answer using this context:\n{context}\n\nQuestion: ...")
The vector database is the engine behind step two. Without it, the model is guessing from training data instead of grounding its answer in your actual sources.
Key Features to Compare
Not all vector stores are equal. When you evaluate one, these are the dimensions that matter in production:
| Feature | Why it matters |
|---|---|
| ANN algorithm and tuning | Controls the speed vs recall tradeoff |
| Metadata filtering | Real queries scope by tenant, date, source |
| Scale limits | Millions vs billions of vectors behave differently |
| Update and delete | Fresh data means re-indexing, not just inserting |
| Hybrid search | Combining vector and keyword search improves recall |
| Hosting model | Managed service vs self-hosted vs a DB extension |
| Cost model | Per-vector, per-query, or per-node pricing |
If you want a performance-focused comparison of the popular options, we cover it in fastest vector databases 2026. The right pick depends on your scale, your latency budget, and whether you would rather run infrastructure or pay for a managed service.
When pgvector Is Enough
Here is the part vendors will not lead with: you may not need a dedicated vector database at all.
If you already run PostgreSQL, the pgvector extension adds vector columns and similarity search directly to your existing database. For projects up to a few million vectors, this is often the pragmatic choice. You keep your data in one place, you get transactions and joins and your normal backups, and you avoid running and syncing a second system.
Reach for pgvector or a similar DB extension when:
- Your corpus is in the thousands to low millions of vectors.
- You already have a relational database and want to keep operations simple.
- Your queries mix vector search with normal SQL filters and joins.
Reach for a dedicated vector database when:
- You are scaling to tens of millions of vectors or more.
- You need the lowest possible query latency at high volume.
- You want managed sharding, replication, and index tuning handled for you.
Starting with pgvector and graduating to a specialized store when you actually hit its limits is a perfectly respectable path, and it saves you from over-engineering on day one.
Getting Good Data In
A vector database is only as useful as what you put in it. Garbage chunks produce garbage retrieval, so the quality of your source text matters more than the choice of database.
If your corpus comes from the web, the raw HTML is usually a mess of navigation, ads, and scripts that pollute your embeddings. link.sc fetches any URL and returns clean markdown you can chunk and embed directly, which keeps your index full of actual content instead of page furniture. Clean input is the cheapest quality win in the whole pipeline.
The Bottom Line
A vector database stores embeddings and finds the closest ones by meaning, using ANN indexes like HNSW to stay fast at scale. It is the retrieval engine that makes RAG and semantic search work. For serious scale, a dedicated store earns its keep; for most starting projects, pgvector on your existing database is enough. Pick based on your real scale, not the biggest number on a benchmark chart.
Building RAG and need clean text to embed? Fetch model-ready content from any URL with link.sc.