Vector databases have a dirty secret: the embeddings often dwarf the source data. Index 60M documents and you may be carrying 201GB of float vectors. LEANN's bet is that most of those vectors are never read during any given query, so storing them all is waste. It keeps a pruned graph and recomputes embeddings on the fly only for the handful of nodes a search actually visits.
How It Works
The index is a high-degree-preserving pruned proximity graph plus the raw text, not a vector store. During traversal LEANN regenerates embeddings for visited nodes using the original model, trading a bit of compute for an order-of-magnitude smaller footprint.
- 60M-document index: 6GB instead of 201GB, a 97% reduction
- Personal corpora shrink hard too: 780K email chunks at 79MB (vs 2.4GB), 400K chat messages at 64MB, 38K browser entries at 6.4MB
- HNSW backend maximizes savings via full recompute; DiskANN backend trades some storage back for PQ-accelerated traversal
- Recall stays close to solutions that store every vector
Who It's For
Great fit if you want private, on-device semantic search over your own data — Apple Mail, Chrome history, WeChat, iMessage, exported ChatGPT/Claude logs, or a codebase with AST-aware chunking — without shipping embeddings to a server or paying for hundreds of gigabytes. Look elsewhere if your workload is latency-critical at high QPS: recomputing embeddings per query costs CPU/GPU time that a fully materialized vector index avoids. The tradeoff is deliberate — storage for compute.