Embeddings & Vector Search· Lesson 5 of 7
Vector Databases
In one line · A vector database stores millions of embeddings and finds the nearest matches to your query in milliseconds — without comparing them one by one.
Searching a million vectors the naive way is unbearably slow; vector DBs use smart indexing (ANN) to keep search fast as you scale.
Instead of scanning every shelf in the warehouse, the index takes you straight to roughly the right shelf — trading a little accuracy for huge speed.
Like finding a word in a dictionary: you don't read every page, you jump straight to the right letter. The index does that same jump across millions of vectors — getting you near the right spot without scanning each one.
On Cloudflare you'd use Vectorize: you load your chunk vectors once, then each query returns the top-5 nearest results ready to hand to the model.
Exact 100% search (exact k-NN) means comparing the query with every vector — O(n) and impractical at millions. So vector DBs build an ANN (Approximate Nearest Neighbor) index; the most popular algorithm is HNSW: a multi-layer graph where upper layers hold 'highways' between distant regions and lower layers hold fine-grained links. A query descends layer by layer, getting closer at each step — inspecting a tiny fraction of vectors and finding the 'approximately' nearest. That approximation is the price: it can occasionally miss the true nearest neighbor (recall below 100%), and you can tune parameters to trade speed against accuracy.
🧪 Try it: store the vectors of 20-30 text chunks in a vector index (Vectorize, say), then query with 3 different questions and inspect the top-5 with their similarity scores. Then compute the same queries by brute force (cosine against every vector) and compare the two rankings — at this small scale they'll match exactly, which shows you precisely what the index 'approximates' once the scale grows.
The biggest mistake: assuming results are 100% guaranteed — ANN is approximate by design; a near neighbor occasionally vanishing isn't a bug, it's the deal itself. Second: running a full vector database (with its cost and complexity) for ten thousand vectors — those brute-force in milliseconds. Third: neglecting metadata filtering — filtering after the search instead of letting the DB filter inside the query, leaving you with fewer results than you asked for.
Use one when your vectors run to hundreds of thousands or millions, or when you need continuous index updates, metadata filtering, or managed infrastructure like Vectorize instead of running the indexing yourself.
Under ~100k vectors, in-memory brute force (or the pgvector extension in the database you already run) is usually simpler and plenty fast — and gives you 100% exact results with no approximation. Don't add a new system to your stack before you actually need it.