Two stores, one interface, different answers
Real approximate indexes (IVF, HNSW) are smarter than four buckets, but they make the same trade: look at less, risk missing a neighbour near a boundary.
Vector stores come in four families: dedicated vector databases, search engines with vector fields, extensions to a database you already run, and embedded libraries. They differ in where the data lives and who operates it, not in what a search means.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 5 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Write family(vectors, uses_postgres) that returns "embedded", "extension" or "dedicated" using rules of your choice, and print it for these three profiles: (a) 5,000 vectors in a single-process tool, (b) 2 million vectors in a product that already uses PostgreSQL, (c) 400 million vectors that need many machines. Print the answer for each.
Write recall_at_k(exact_ids, found_ids) that returns the fraction of exact ids that the approximate result found. Print it for exact ["c", "d"] and found ["c", "b"].
Explain it without notes
Name the four families of vector stores and one example of each.
What does every vector store have in common, whatever the family?
Why can an approximate store miss a true nearest neighbour?
What makes a late move between stores expensive?
Expected output
query 85 deg: exact c,d (10 compared) | bucket c,b (3) | widened c,d (8)
query 20 deg: exact a,b (10 compared) | bucket a,b (3) | widened a,b (8)
query 230 deg: exact h,g (10 compared) | bucket h,g (2) | widened h,g (7)