What is DiskANN?
DiskANN is a family of techniques for building graph-based vector indexes that live on disk rather than entirely in memory. Traditional vector search engines (like FAISS or HNSWlib) require the full index to fit in RAM, which becomes expensive or impossible at scale. DiskANN’s key insight is that careful disk layout, combined with graph-based navigation, can achieve near in-memory search speeds while storing data on SSD. Meilisearch builds on this approach by combining HNSW (Hierarchical Navigable Small World) graph navigation with LMDB persistence, giving you fast vector search without RAM limitations.Hannoy: Meilisearch’s DiskANN implementation
Hannoy implements the core DiskANN principles with HNSW as the graph structure and LMDB as the storage backend. It replaced Arroy, Meilisearch’s previous vector store based on hyperplane trees (k-d trees).Why Hannoy replaced Arroy
While Arroy worked well for lower dimensions, it had limitations:| Issue | Impact |
|---|---|
| Dimension sensitivity | Performance degraded significantly beyond ~20 dimensions |
| Leaf node comparisons | Required comparing against all vectors in leaf nodes |
| Read-heavy indexing | Over 90% of indexing time spent on I/O and page faults |
| Complex maintenance | Tree balancing and temporary file management |
Performance improvements
Benchmarks on 1 million documents show dramatic improvements:768-dimensional embeddings
| Metric | Arroy | Hannoy | Improvement |
|---|---|---|---|
| Build time | 2,387s | 506s | 4.7x faster |
| Search latency | 190ms | 29ms | 6.5x faster |
| Disk usage | 16.19 GiB | 4.03 GiB | 4x smaller |
1536-dimensional (quantized)
| Metric | Arroy | Hannoy | Improvement |
|---|---|---|---|
| Build time | 141s | 67s | 2x faster |
| Search latency | 168ms | 13ms | 13x faster |
| Disk usage | 1.86 GiB | 481 MiB | 4x smaller |
How it works
HNSW graph navigation
Hannoy organizes vectors into a hierarchical graph structure:- Enter at the top layer (sparse, enables fast navigation)
- Greedily navigate toward the query vector
- Descend to the next layer at each local minimum
- Return nearest neighbors from the bottom layer
Disk-backed storage with LMDB
Following the DiskANN philosophy, Hannoy stores the graph structure in LMDB rather than in RAM:- Disk-backed: Handle datasets larger than available RAM
- Memory-mapped: OS manages caching automatically
- Concurrent reads: Multiple search threads simultaneously
- ~200 bytes overhead per vector for graph edges
Incremental updates
Unlike tree-based approaches requiring rebalancing, Hannoy handles updates efficiently: Insertions:- New vectors added to an in-memory temporary index
- When threshold reached, merges with disk index using streaming operations
- Only ~1% of vectors need re-indexing during merge
- Uses DiskANN-style deletion policy
- Patches neighboring links to maintain graph connectivity
- No tombstones or graph gaps
Quantization support
Binary quantization reduces storage and improves speed for high-dimensional embeddings:| Dimensions | Full precision | Quantized |
|---|---|---|
| 768 | 3 KiB/vector | ~100 bytes/vector |
| 1536 | 6 KiB/vector | ~200 bytes/vector |
| 3072 | 12 KiB/vector | ~400 bytes/vector |
Distance metrics
| Metric | Use case |
|---|---|
| Cosine | Text embeddings (normalized) |
| Euclidean | General purpose |
| Dot product | When vectors are pre-normalized |
| Hamming | Binary/quantized vectors |
Filtered search
Hannoy integrates with Meilisearch’s filtering using RoaringBitmaps:Multiple embedders
Configure different embedders for different use cases:Configuration
Memory prefetching: Reduce cold-start latency by preloading graph structure:Related concepts
- AI-powered search: Using vector search in Meilisearch
- Storage: The LMDB storage backend
Next steps
- Hannoy on GitHub: Source code
- From Trees to Graphs: Speeding Up Vector Search 10x: Technical deep-dive