Chapter 8 · Vector Databases

Search by meaning,
at scale.

A normal database finds things by exact match. A vector database answers a completely different question — "give me the ones most similar to this."

The job

Store, index, search — millions of vectors.

A vector database does one thing extremely well: it holds millions of high-dimensional vectors — the fingerprints from Chapter 7 — and searches them by similarity.

Store

Keep millions of high-dimensional vectors on hand.

Index

Pre-organize them so search doesn't start from scratch.

Search

Return the closest vectors to a query — fast.

That single ability turns a pile of embeddings into a memory you can actually query.

The mismatch

Why a normal database can't do this.

A regular database is a master of exact questions — find the row where email equals this, orders between March and May. Exact match and range, and it's brilliantly fast because it can jump straight to the answer.

But "which vectors mean something similar?" isn't an exact question.

No stored vector is equal to your query. You want the closest points in a 1,000-dimensional space — a nearest-neighbor question, not a lookup.

The naive way

Brute force: measure everything.

The obvious approach — compare the query to every single stored vector, then keep the smallest distances. With a thousand vectors that's fine.

With ten million, it's impossibly slow.

Checking them one-by-one on every search means waiting seconds for a single lookup. A vector database exists to make that search feel instant instead.

The whole idea in one picture

Brute force vs. HNSW.

Grey dots are stored vectors; the pink dot is the query. Left: brute force touches every dot. Right: HNSW hops a few links and lands on the answer.

Brute force ~40 comparisons query HNSW ~5 comparisons query

The big idea

HNSW: a smart graph you navigate.

HNSW — hierarchical navigable small world — pre-wires the vectors into a graph of short links. To search, you don't visit every point; you start somewhere and hop along edges toward the query, greedily getting closer each step.

The trade

Give up a tiny sliver of accuracy — it might occasionally miss the true nearest.

The payoff

A massive speedup — roughly 40 comparisons vs. 5, and it only widens as data grows.

Approximate, but so close it doesn't matter — and fast enough to feel instant.

Measuring "close"

How do we score "similar"? Cosine.

To find the nearest vectors, the database needs a way to score how close two of them are. For text, that's almost always cosine similarity — it measures the angle between two vectors, not the raw distance between their tips.

Two fingerprints pointing the same direction count as similar even if one is "longer" — exactly what you want when a short phrase and a long paragraph mean the same thing.

Closer angle = more similar meaning.

Coming up

We'll deep-dive cosine next chapter.

Chapter 9 · Embeddings unpacks cosine similarity properly — the geometry, the intuition, and why the angle matters more than the length.

For now, hold the one-liner: closer angle = more similar meaning.

The landscape

You don't build HNSW — you pick a database.

They all do the same core job. They differ in how they're run, what extra tricks they add, and how far they scale. Here's the field, with a "reach for this when…" for each.

Pinecone

Managed cloud, no servers. Reach for production search without operating anything.

Weaviate

Vector and keyword search fused. Reach for hybrid retrieval from one engine.

Qdrant

Rust, blazingly fast, rich filtering. Reach for it when speed and metadata filters matter.

Chroma

Easiest to start — runs local, zero setup. Reach for it to prototype and build fast.

Milvus

Billions of vectors, enterprise scale. Reach for it when the dataset is enormous.

pgvector

Adds vectors to PostgreSQL. Reach for it when you already run Postgres.

Don't overthink it

Prototype on Chroma. Ship on Pinecone or Qdrant.

🧪 Prototype

Chroma

Runs locally, zero setup. You'll be doing similarity search in about five minutes.

🚀 Production

Pinecone or Qdrant

Managed cloud or fast-and-filterable. Covers the vast majority of real projects.

That's the whole decision for most teams — start easy, move to production when it's real.

The one thing to remember

A vector DB is the agent's memory bank.

Fast, approximate similarity search is the machinery that makes RAG and agent memory practical at scale. Without it, "remember everything and recall what's relevant" would simply be too slow to use.

Chapter 8 in one breath

Find the closest, not the exact.

A vector database stores millions of vectors and answers one question fast: which are most similar to this? Brute force checks everything; HNSW hops a smart graph and checks a handful. Cosine is the yardstick.

Prototype on Chroma; ship on Pinecone or Qdrant.

Next up

Chapter 9 · Embeddings.

We've built the memory that stores and searches the fingerprints. Next we open the fingerprints themselves — how embeddings are made, and the geometry of cosine similarity we kept promising.

Press S for speaker notes · F for fullscreen · to advance.