Week 2 · Field guide · Retrieval storage

Vector Databases

The store for your embeddings and similarity search, with metadata filtering: pgvector, Qdrant, Weaviate, Pinecone, Chroma, and Milvus, and how to choose between them.

vector storecomparisonself-host + managed

What it is

The store behind retrieval.

A vector database holds your embeddings and answers similarity queries, usually with metadata filtering so you can scope a search to a tenant, date range, or document type. The field is crowded: pgvector, Qdrant, Weaviate, Pinecone, Chroma, and Milvus each make a different bet on ops, scale, and features. They all do the same core job; the choice is about how much operational weight you want to carry and what you need beyond plain top-k.

The one job

Return the k most similar chunks, fast.

Given a query embedding, retrieve the k nearest stored vectors quickly, with metadata filtering to narrow the candidate set. Everything else, the connectors, the dashboards, the managed hosting, is packaging around that one operation.

How to choose

Start with pgvector: the right answer for roughly 80% of RAG under 10M vectors, keeping embeddings beside your relational data.
Outgrow it and go Qdrant (fastest self-host, great filtering) or Pinecone (managed default, least ops, premium price).
Need native hybrid search or multi-tenant isolation? Choose Weaviate.
Want the easiest local or dev start? Chroma. At billions-scale, Milvus.

pgvector

Postgres extension. The boring default: embeddings beside your relational data, no new system.

Qdrant

Fastest self-host, excellent metadata filtering. The step up when pgvector runs out.

Weaviate

Native hybrid search and multi-tenant isolation built in.

Pinecone

Managed default, least ops to run, at a premium price.

Skip it when

You have very few documents: a simple in-memory list or plain SQL is fine.
You are optimizing the store before the embedding model: the model affects retrieval quality more than the database.
You added a separate system when pgvector beside your existing Postgres would have done the job.

A minimal look

pgvector is just a query.

-- store: an embedding column beside your normal rows
-- query: order by cosine distance to the query vector
SELECT id, content
FROM chunks
WHERE tenant_id = 'acme'          -- metadata filtering
ORDER BY embedding <=> '[query_vector]'  -- <=> is cosine distance
LIMIT 5;                          -- the k most similar

The principle it teaches

Course principle

The embedding model affects retrieval quality more than the database choice. Prefer the boring default, pgvector, until you have a concrete reason to move: a scale ceiling, a hybrid-search need, or an ops constraint you can name.

Where it fits your labs

This is a Week 2 tool. Lab 2 stores its chunks in pgvector so you feel how retrieval works before reaching for a managed service, and so the database is one variable you can hold steady while you tune the parts that matter more.

Use in

Lab 2 (hybrid RAG), backed by pgvector for storage.

week 2

Pairs with

An embedding model that drives retrieval quality, and a reranker for precision.