Skip to main content

Documentation Index

Fetch the complete documentation index at: https://www.meilisearch.com/docs/llms.txt

Use this file to discover all available pages before exploring further.

Meilisearch stores and searches vector embeddings using a disk-backed approximate nearest neighbor (ANN) approach inspired by DiskANN, Microsoft’s research on graph-based vector search that scales beyond RAM. The implementation lives in Hannoy, Meilisearch’s purpose-built vector store library introduced in v1.29.

​
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:
IssueImpact
Dimension sensitivityPerformance degraded significantly beyond ~20 dimensions
Leaf node comparisonsRequired comparing against all vectors in leaf nodes
Read-heavy indexingOver 90% of indexing time spent on I/O and page faults
Complex maintenanceTree balancing and temporary file management
Hannoy addresses all these issues using a graph-based approach.

​
Performance improvements

Benchmarks on 1 million documents show dramatic improvements:

​
768-dimensional embeddings

MetricArroyHannoyImprovement
Build time2,387s506s4.7x faster
Search latency190ms29ms6.5x faster
Disk usage16.19 GiB4.03 GiB4x smaller

​
1536-dimensional (quantized)

MetricArroyHannoyImprovement
Build time141s67s2x faster
Search latency168ms13ms13x faster
Disk usage1.86 GiB481 MiB4x smaller
Real-world impact: One customer’s indexing time dropped from 2 months to 6 seconds.

​
How it works

​
HNSW graph navigation

Hannoy organizes vectors into a hierarchical graph structure: 
Layer 2:    A -------- D              (sparse, long-range links)
            |          |
Layer 1:    A -- B --- D -- E         (medium density)
            |    |     |    |
Layer 0:    A-B-C-D-E-F-G-H-I-J      (all vectors, short links)
Search process:
  1. Enter at the top layer (sparse, enables fast navigation)
  2. Greedily navigate toward the query vector
  3. Descend to the next layer at each local minimum
  4. Return nearest neighbors from the bottom layer
This “small world” property, where any vector can reach any other through few hops, enables efficient search without checking every vector.

​
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
This is the key advantage over in-memory-only solutions. Your dataset size is limited by disk space, not RAM.

​
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
Deletions:
  • 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:
DimensionsFull precisionQuantized
7683 KiB/vector~100 bytes/vector
15366 KiB/vector~200 bytes/vector
307212 KiB/vector~400 bytes/vector
Quantized vectors use Hamming distance for extremely fast comparisons.

​
Distance metrics

MetricUse case
CosineText embeddings (normalized)
EuclideanGeneral purpose
Dot productWhen vectors are pre-normalized
HammingBinary/quantized vectors
Hannoy integrates with Meilisearch’s filtering using RoaringBitmaps: 
POST /indexes/products/search
{
  "vector": [0.123, 0.456, ...],
  "filter": "price < 50 AND in_stock = true",
  "hybrid": {
    "semanticRatio": 1.0,
    "embedder": "default"
  }
}
The filter is evaluated first, then HNSW search operates only on matching documents.

​
Multiple embedders

Configure different embedders for different use cases: 
PATCH /indexes/products/settings
{
  "embedders": {
    "text": {
      "source": "openAi",
      "model": "text-embedding-3-small",
      "documentTemplate": "{{doc.title}} {{doc.description}}"
    },
    "image": {
      "source": "userProvided",
      "dimensions": 512
    }
  }
}
Each embedder maintains its own HNSW graph.

​
Configuration

Memory prefetching: Reduce cold-start latency by preloading graph structure: 
export HANNOY_READER_PREFETCH_MEMORY=true
This can reduce initial search latency by several milliseconds.

​
Next steps