Vector DB & ANN · advanced
Disk-Based ANN
DiskANN and SPANN — serving vector indexes that do not fit in memory.
Mental model
An in-memory graph index like HNSW is bounded by RAM, so at billion scale the index has to live on SSD — and then the cost model inverts: what matters is not comparisons but the number of random reads, because each one costs a hundred microseconds. DiskANN's answer is to keep compressed vectors in memory to guide the search and touch the SSD only for the few full-precision neighbourhoods it actually needs, so a query costs a handful of reads rather than a traversal's worth.
How to study Disk-Based ANN
Begin by restating the mental model in your own words, then connect it to a concrete system you have built or operated. Name the mechanism, the constraint it addresses, and the trade-off it introduces. Use the linked roadmap and primary implementation references to check details, but close the source before writing your explanation. Retrieval is the learning step; rereading is only preparation.
Next, compare Disk-Based ANN with Scalar & Binary Quantization, Compute, Memory & Storage Hierarchy. Ask what changes in correctness, latency, resource use, operability, and failure recovery. Complete Cost a disk-resident search by I/O and preserve the command, input, output, and one failed attempt as evidence. Finish by explaining the idea without jargon to someone who has not studied the track.
Proof of understanding
- Explain the mechanism from first principles and identify the state it reads or changes.
- Give one situation where the concept is the right choice and one where it is not.
- Predict a realistic failure mode before running the drill, then compare the prediction with evidence.
- Connect the result to a roadmap or build artifact instead of treating the concept as isolated trivia.
Where it matters
Billion-scale retrieval on commodity hardware, where an all-in-RAM index would cost an order of magnitude more.
Common mistakes
- Carrying over in-memory intuition and optimising comparison count instead of I/O count
- Ignoring that SSD random-read latency, not bandwidth, sets the query floor
- Rebuilding the whole index for small update volumes rather than maintaining a delta
- Benchmarking with a warm page cache, which hides the disk cost entirely
Learn from primary sources
Use the linked roadmap context and practice prompt.
Practice and explain it back
Cost a disk-resident search by I/O
Implement queryCost({hops, neighboursPerHop, cachedFraction, readLatencyUs, compareLatencyNs}) returning { randomReads, totalUs } rounded to 2 decimals. Every hop fetches neighboursPerHop nodes; a cachedFraction of them avoid the SSD. Comparisons cost compareLatencyNs each and happen for every fetched neighbour.
Expected evidence: With SSD reads at 100us, I/O dominates comparisons by orders of magnitude.
Open the interactive drill →Review prompts
- Moving an ANN index from RAM to SSD inverts what you optimise. What becomes the cost, and how does DiskANN keep it low?
Build evidence
Use a roadmap capstone to turn this concept into working evidence.