Vector Databases: Where Embeddings Actually Live

A vector database stores embeddings and finds the closest matches fast - the storage layer behind most RAG and semantic search systems.

What it stores

An embedding turns a piece of text, image, or audio into a list of numbers that captures its meaning. A vector database is built to store millions of these number lists and answer one question fast: which stored vectors are closest to this new one? That's different from a normal database, which matches exact values, not closeness.

What it's for

Vector databases sit underneath most RAG (Retrieval-Augmented Generation) systems and semantic search features. When you ask a question, your query gets embedded too, and the database returns the stored chunks whose vectors sit nearest to it - usually the chunks most relevant to what you asked, even without a shared exact word.

Some names you'll run into

pgvector adds vector search directly to a regular Postgres database - handy if you already run Postgres. Qdrant and Chroma are dedicated vector databases built for this job, with more specialized indexing and filtering. There are several others; these three come up often in tutorials and small projects.

When you don't need one

If your entire knowledge base is small enough to fit in the model's context window, you don't need a vector database - just put the text directly in the prompt. A vector database earns its complexity once your data is too big for that, changes often, or only a small, shifting slice is relevant to any given question.

EXAMPLE

SQL with pgvector: CREATE EXTENSION vector; CREATE TABLE docs (id bigserial, content text, embedding vector(1536)); SELECT content FROM docs ORDER BY embedding <-> '[0.01, -0.02, ...]' LIMIT 5;

🛠️ EXERCISE — TRY IT YOURSELF

Decide, for one of your own small projects, whether it actually needs a vector database.

Estimate roughly how large your knowledge base or document set is, in pages or tokens.
Check whether that would fit comfortably inside a large context window (e.g. 100,000+ tokens).
If it fits, sketch how you'd just paste it directly into a prompt instead of building retrieval.
If it doesn't fit, look up pgvector, Qdrant, or Chroma's quickstart and note the smallest setup that would work for your case.

✅ SELF-CHECK

☐ Did you estimate how many chunks your knowledge base has?
☐ Did you actually try both approaches, not just think them through?
☐ Do you now know which approach means less effort for your project?

QUICK QUIZ

When do you NOT need a vector database?