chapter 16 · part 3
Vector databases
the hook
You wrote cosine similarity over a loop. Now see what ChromaDB does when there are 10 million chunks.
the idea
You already wrote cosine similarity by hand in ch15. A vector database is that same operation, industrialized — the same math, just engineered to handle millions of vectors without grinding to a halt.
The dumbest approach (brute force) checks EVERY vector, every single query. Correct, but it doesn't scale — double the vectors, double the search time, forever.
Real vector databases use an index — a pre-organized structure that lets you skip most of the comparisons entirely. Below uses the simplest real version: group vectors into buckets by rough location, then only search the bucket your query lands in.
This is a genuine simplified version of what FAISS, Pinecone, and Chroma actually do (called an IVF index — 'inverted file' index) — same idea, way more engineering polish. Race it against brute force below and watch the gap widen as N grows.
playground — your hands now
what: race brute-force cosine similarity against a simple bucketed index over up to 100,000 vectors, with real timings.
why: this is the exact tradeoff every vector database (Pinecone, Chroma, FAISS) is built to solve — search speed at massive scale.
how: drag N, hit race, watch the real millisecond timings and the speedup ratio.
start here → drag N up to 100,000, predict, then hit race and read the real timings.
predict first: at this N, will brute force or the bucketed index be faster?
try this
Push N to 100,000 and race. Note the speedup ratio. Now drop N to 200 and race again — the gap nearly disappears. Indexes earn their keep at scale, not on small data — that's why nobody bothers with a vector database for 50 documents.
checkpoint
1. Why does brute-force search get slower as N grows, but a bucketed index barely does?
2. What's the real-world name for the bucketing technique demonstrated here?
recap card — keep this
vector DBs = your cosine similarity + clever indexing + scale.