LEANN: A Vector Database That Recomputes Embeddings to Cut Storage by 97%

What LEANN Solves and Who It Is For

LEANN is a vector database that aims to make retrieval-augmented generation (RAG) practical on a personal laptop. The core problem it addresses is storage: traditional vector databases store an embedding for every chunk of text, which can consume hundreds of gigabytes for millions of documents. LEANN claims to reduce storage by 97% without accuracy loss by storing only a graph structure and recomputing embeddings on demand. This is aimed at individuals who want to index personal data, such as emails, browser history, chat logs, or entire codebases, all while keeping data local and private. The README emphasizes zero telemetry and no cloud dependence, positioning LEANN as a tool for privacy-conscious users who are tired of sending personal data to external services. It also targets developers using coding agents like Claude Code, where semantic search over a repository can improve context retrieval compared to keyword-based grep.

The Mechanism: Graph-Based Selective Recomposition

The core innovation in LEANN is what the README calls 'graph-based selective recomputation with high-degree preserving pruning.' Instead of storing a dense vector for every text chunk, LEANN builds a graph where nodes represent chunks and edges capture relationships. The embeddings are not persisted; they are computed on the fly during query time. The pruning step keeps high-degree nodes that are likely to be important, reducing the graph's memory footprint. The graph is stored in a compressed sparse row (CSR) format, which is a standard way to store sparse matrices efficiently. This means that when you query, the system must recompute embeddings for candidate chunks, trading storage for CPU cycles. The paper (arXiv:2506.08276) is cited as the source of this method, but the README does not provide detailed pseudocode. The trade-off is clear: you save disk space and RAM, but you pay with increased computation during each query. This design is a deliberate departure from typical vector databases like FAISS, which store all vectors and rely on fast approximate nearest neighbor search.

Getting Started: Installation and First Steps

The installation instructions are straightforward and rely on the uv package manager. First, install uv, then clone the repository and create a virtual environment. The README shows these commands: curl -LsSf https://astral.sh/uv/install.sh | sh, git clone https://github.com/yichuan-w/LEANN.git leann, cd leann, uv venv, source .venv/bin/activate, uv pip install leann (the text is truncated but this is the clear intent). The package is available on PyPI, and the repository includes examples for various data sources, such as PDFs, Markdown files, Apple Mail, WeChat, iMessage, ChatGPT, Claude, Slack, Twitter bookmarks, and a Claude Code integration. The README mentions a separate package, packages/leann-mcp, which provides a Model Context Protocol (MCP) server for integration with Claude Code. This suggests that LEANN is designed not just as a library but as a service that can plug into AI assistants. The Python version support spans 3.10 through 3.14, and the platform badges claim support for Ubuntu, Arch, WSL, macOS (ARM64 and Intel), and Windows, though the README does not provide details on Windows-specific setup.

Storage Savings and the 'No Accuracy Loss' Claim

The headline claim is that LEANN can index 60 million text chunks in 6 GB instead of 201 GB, a 97% reduction. This is a dramatic figure, and the README says that this is achieved without accuracy loss. However, the basis for this claim is not fully detailed in the README; it points to the paper and to benchmark figures for coding agents. The contextbench benchmark shows that LEANN outperforms BM25 on relevant-code recall and exploration coverage, but that is a comparison against a keyword baseline, not against a traditional vector database. The claim of 'no accuracy loss' relative to 'heavyweight solutions' is plausible only if the recomputation method preserves the same embedding quality as storing all vectors. The README does not provide a direct comparison against FAISS or other vector stores on the same dataset. As a reviewer, I would treat this claim with caution until you reproduce it on your own data. The storage savings are real in principle, but the accuracy equivalence depends on the graph structure and the embedding model, which are not specified in the README.

Use Case: Making Coding Agents Smarter

One of the most concrete applications described is using LEANN as a semantic search service for Claude Code. The README reports a benchmark on 30 SWE-Bench Pro tasks from ContextBench, where LEANN was compared to BM25. The results show that with LEANN, the agent achieved 2.1 times the initial relevant-code recall (24.2% vs 11.4%), and 12.6 percentage points higher relevant-code coverage after exploration (38.4% vs 25.8%). The agent also used 8.4% fewer tokens (3.22M vs 3.51M). These numbers are specific and reproducible because the benchmark is in benchmarks/contextbench/README.md. The key point is that LEANN surfaces relevant code earlier, allowing the agent to focus its context window on reasoning rather than scanning. This is a strong use case because coding agents often struggle with large repositories, and keyword search misses synonyms and conceptual matches. However, the README notes that better context access does not guarantee issue resolution, so the practical benefit may vary.

Limitations and When It Is the Wrong Tool

LEANN's design has clear trade-offs. The most obvious limitation is that recomputing embeddings on the fly requires significant CPU resources at query time. For a laptop, this could mean slower response times compared to a system that precomputes and stores vectors. The README does not provide latency benchmarks, so this remains an unknown. Another limitation is that the graph-based approach may not be suitable for all data types. For example, if you have a corpus that changes frequently, the graph must be updated, and the recomputation strategy may not handle dynamic updates efficiently. The README does not discuss incremental indexing or deletion. Additionally, the claim of 'no accuracy loss' is not substantiated with a direct comparison against a traditional vector database in the README. If you need exact, deterministic search and can afford the storage, a simple vector store might be more appropriate. Also, the README mentions that GPU acceleration is not yet available, so if you are working with very large datasets or need high throughput, LEANN may not be the right tool. The project is under active development, with recent releases in 2025 and 2026, but the README does not specify a roadmap beyond v0.4.

Alternatives and How They Differ

The most direct alternative is FAISS, a vector database that stores all embeddings in memory and uses approximate nearest neighbor search. FAISS is optimized for speed and scalability, but it requires significant storage for large corpora. LEANN's approach is fundamentally different: it does not store embeddings, so it saves space but adds computational overhead at query time. Another alternative is a traditional RAG pipeline using an embedding model and a vector store like Chroma or Weaviate, which also store all vectors. The key difference is that LEANN's recomputation strategy is a novel trade-off that is not present in these systems. For coding agents, BM25 is a baseline that LEANN explicitly compares against, and LEANN claims to be a drop-in semantic search MCP service for Claude Code, whereas BM25 is a keyword-based method that cannot capture semantic similarity. If you need exact keyword matching, BM25 is simpler and faster, but if you need semantic search, LEANN offers a storage-efficient option.

Maintenance and License Implications

LEANN is licensed under the MIT license, which is permissive and allows commercial use, modification, and redistribution. This is a positive for adoption, as it does not impose copyleft obligations. The project is actively maintained, with the last push in September 2026 and releases as recent as March 2026, indicating ongoing development. The README does not provide detailed documentation on the internal APIs or how to extend the graph structure, which could be a maintenance challenge for users who need to customize the behavior. The dependency on the uv package manager is a specific choice that may require users to adopt a new tool, but uv is becoming a standard for Python project management. The MCP integration is an additional package, which suggests that the core library is separate from the integration layer, making it easier to update independently. However, the README does not mention how versioning works for the MCP package relative to the core library. As with any open-source project, you should monitor the issue tracker for known bugs, especially around the recomputation algorithm, which is complex and may have edge cases.

Editorial conclusion

Adopt LEANN if you run RAG on a personal device with limited storage, need privacy, and can tolerate higher CPU use for on-demand embedding computation. Skip it if you require deterministic, low-latency search on massive static corpora or need GPU acceleration, which is not yet available. Before adopting, verify that your data types and query patterns match the graph-based approach by running the benchmarks in the benchmarks/contextbench directory and testing with your own documents, especially if you rely on exact keyword matching.

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. StarTrail-org/LEANN on GitHub