Vector Search easy
You need to search 2 billion vectors on a limited hardware budget, and a p99 latency of around 50 ms is acceptable. Which index design fits best?
- A A fully in-memory HNSW index, since it gives the lowest latency regardless of hardware cost.
- B A flat brute-force index, since exact search scales fine to billions of vectors on one node.
- C A post-filtered index, since filtering after search keeps the memory footprint of the graph small.
- D A disk-based index with compressed vectors in RAM, trading some latency for a much lower cost.
Answer: D. A disk-based index with compressed vectors in RAM, trading some latency for a much lower cost.
At about 6 KB per vector, 2 billion vectors is roughly 12 TB raw, and in-memory HNSW would need far more RAM once graph overhead is added. A **disk-based** index keeps compressed codes in RAM and full vectors and graph on SSD, which meets a tens-of-milliseconds budget at a fraction of the cost. In-memory HNSW is the right choice when you need single-digit millisecond latency and the budget allows it.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- You are building an IVF index on 20 million vectors. A teammate asks why the build needs a 'training' step before any vectors can be added. What is the reason?
- An HNSW index serves a marketplace where about 30% of listings are updated or removed each week. Each update is applied as a delete plus an insert, and deletes mark tombstones. Over a month, recall@10 drifts from 97% to 89% and p99 latency rises at the same ef_search. What is happening, and what should you do?
- Users delete documents in your primary database, but the deleted documents keep appearing in vector search results for hours. The vector index is rebuilt nightly. What is the best fix?
- Your embedding model outputs unnormalized vectors whose magnitudes vary widely. A teammate wants to switch the index from cosine similarity to dot product because it is cheaper to compute. What is the consequence?
- You are setting an SLO for a new ANN-backed recommendation search over 50 million vectors. A product manager asks for 100% recall@10 with single-digit millisecond latency. What is a realistic response?
- A B2B SaaS app serves 500 customers, and every query searches only one customer's documents. One large customer runs heavy batch queries that slow down search for everyone. Which sharding approach fits best?