graphrag-rs: A Rust GraphRAG Implementation With Three Deployment Paths
GraphRAG-rs is a high-performance, state-of-the-art Rust implementation of GraphRAG (Graph-based Retrieval Augmented Generation) that builds knowledge graphs from documents and enables natural language querying with configurable entity extraction and local LLM integration
At a glance
- What is it?
- graphrag-rs builds knowledge graphs from documents and answers natural language questions over them, with a server build, a browser-only WASM build, and a hybrid path that is documented as planned rather than shipped. The CLI is the part worth evaluating first.
- Who is it for?
- Adopt graphrag-rs if you want a Rust-native GraphRAG pipeline and can accept the documented defaults (hash-fallback embeddings, pattern-based entity extraction) or run Ollama yourself for real embeddings. Do not adopt it if you need the hybrid architecture now, since the README states it is designed but implemented in Phase 3, or if you need a published crate version, since the quick start uses cargo install --path.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 105 days ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem graphrag-rs addresses
Plain vector search over chunks loses the relationships between the things a document mentions. GraphRAG, the pattern this project implements, extracts entities and the edges between them into a graph, then retrieves over that graph instead of over isolated text spans. graphrag-rs is a Rust implementation of that pattern, distributed as a workspace containing at least a CLI crate (graphrag-cli), a library crate (graphrag), a server binary (graphrag-server) and a WASM front end (graphrag-wasm). The README frames the audience as people who want a knowledge graph built from their own documents and queried in natural language, and it targets three deployment shapes: a server, a 100 percent client-side browser build, and a hybrid of the two. The Rust angle matters for two reasons the material makes explicit: a single release binary reported at 5.2MB, and the ability to compile the same pipeline to wasm32-unknown-unknown. If you are already running Python GraphRAG variants and the deployment weight is the pain point, that is the gap this fills.
How the pipeline and its retrieval layers fit together
The flow visible in the README is index then ask. graphrag index ./mydoc.txt builds a persistent workspace directory, shown as ./graphrag-data, and graphrag ask "..." answers from that graph. Underneath, documents are chunked, entities and relationships are extracted, and the result is stored as a graph plus embeddings. The README states that the default path uses hash-fallback embeddings and pattern-based entity extraction, with Ollama, GLiNER and custom chunking available through a builder API. Retrieval quality features are listed as production status: LightRAG dual-level retrieval, Leiden community detection, cross-encoder reranking, HippoRAG personalized PageRank, and semantic chunking. A second table adds symbolic anchoring, dynamic edge weighting, causal chain analysis, hierarchical relationship clustering and graph weight optimization. The README attaches quantitative claims to several of these, such as a 6000x token reduction for dual-level retrieval and 10-30x cheaper retrieval for personalized PageRank. Those numbers come from the cited papers, not from a measurement of this codebase, and the README does not present a benchmark harness, so treat them as the authors' summary of the literature rather than as verified behaviour of this crate.
Getting it running: CLI, library and server commands
The quick start is three commands. cargo install --path graphrag-cli installs the CLI from a local checkout, graphrag index ./mydoc.txt builds ./graphrag-data, and graphrag ask "What is the main topic?" queries it. Adding --ollama to either command switches to LLM-quality entity extraction and requires ollama serve running locally. The library path is a single call: GraphRAG::quick_start with the document text, then g.ask("...").await. For the server deployment the README gives a longer sequence: clone the repository, run docker-compose up -d inside graphrag-server to start Qdrant, start ollama serve, run ollama pull nomic-embed-text, export EMBEDDING_BACKEND=ollama, then cargo run --release --bin graphrag-server --features "qdrant,ollama". That EMBEDDING_BACKEND environment variable is the switch between real embeddings and the hash fallback. For the browser build, cargo install trunk wasm-bindgen-cli followed by trunk serve --open inside graphrag-wasm. Note the install command uses a path, not a registry name, so the README as given does not establish that the crates are published on crates.io.
What the hash fallback actually costs you
The default configuration is the most important thing to understand before judging output quality. The README is explicit that the no-config path uses hash-fallback embeddings, which means the vectors are derived from the text by a hash rather than by a semantic model. Retrieval on those vectors will not behave like semantic search, and answers produced without --ollama or without EMBEDDING_BACKEND=ollama should be read as a pipeline smoke test rather than as a quality result. The same applies to pattern-based entity extraction: it finds entities by pattern, so it will not resolve coreference or catch domain-specific names the way a model-driven extractor would. This is a reasonable default for a first run because it needs no services, but it is a trap if you benchmark the tool without switching the backend. The README's own server instructions mark Ollama as required for real semantic search, which is the clearest statement in the material about where the default stops being adequate.
The hybrid architecture is not available yet
The README lists three deployment architectures and marks Server-Only and WASM-Only as production ready, while Hybrid is labelled Planned, with the note that the architecture is designed and implementation is in Phase 3. That is a real limitation, not a roadmap footnote: the option the README calls recommended is the one you cannot run. There is a second boundary in the same area. The WASM build is described as fully functional with ONNX Runtime Web for embeddings and WebLLM with Phi-3-mini for synthesis, and the README cites a demo over Plato's Symposium with 2691 entities. That figure is a property of one demo document, not a capacity statement, and the material gives no memory ceiling, model size limit or document count at which the browser build stops working. If your documents are large or numerous, the server path is the one with a stated scale target (the README mentions over 1M documents for Server-Only), and the browser path has no equivalent number.
How this differs from a Python GraphRAG stack
The obvious comparison is Microsoft's GraphRAG, which is Python and built around LLM-driven entity and relationship extraction plus community summarisation. The difference in approach here is where the work happens and what it compiles to. graphrag-rs is a Rust workspace that produces a single binary and can target wasm32-unknown-unknown, so the same pipeline can run in a browser tab with no backend, which the Python stack does not offer. The trade is ecosystem: a Python GraphRAG deployment assumes a Python runtime and the surrounding tooling, while this one assumes Rust 1.85+, and on Linux the GPU acceleration features pull in Objective-C and GNUstep packages (gobjc, gnustep-devel, libgnustep-base-dev) according to the prerequisites section. That is an unusual dependency set for a Linux server and worth checking before you commit to the feature flags. If your team writes Rust and wants the graph pipeline inside the same binary as the rest of the service, this is the closer fit. If your team lives in Python notebooks and wants the widest set of community integrations, the Python implementations remain the more conventional choice.
Licence, maintenance and upgrade surface
The repository is MIT licensed, which permits commercial use and modification provided the copyright notice and permission notice are retained. That is the standard permissive arrangement, and it is compatible with shipping the binary inside a closed product; this is a description of the licence text, not legal advice, and you should read the LICENSE file in the repository for the operative terms. On maintenance, the material shows the last push on 2026-06-02 and no retrieved releases, so there is no published version history in what was supplied, and the quick start installs from a local path rather than a registry. Practically, that means upgrading is a git pull plus a rebuild rather than a version bump, and you should pin a commit if you depend on it. The feature flags matter for upgrade cost too: the server build in the README uses --features "qdrant,ollama", and the prerequisites list optional dependencies (Ollama, Docker for Qdrant, Trunk for WASM) that each add a moving part to your build and deploy pipeline. The README states that the CLI installs with cargo install --path graphrag-cli, so any change to the workspace layout affects that command.
Who should pick this up, and what to check first
Take graphrag-rs seriously if you want a GraphRAG pipeline written in Rust that you can embed in a service or compile to the browser, and if you are willing to run Ollama for embeddings rather than relying on the hash fallback. The CLI path is the cheapest way to find out whether the extraction quality suits your documents: cargo install --path graphrag-cli, then graphrag index on a file you know well, then graphrag ask with a question whose answer you can check by hand. Run it once without --ollama and once with it, because the two configurations are different products in terms of output quality. Skip it if the hybrid architecture is what you actually need, since the README places that in Phase 3, or if you require a versioned crate from a registry, since the documented install is from a path. The concrete thing to verify before adopting is the Linux build with GPU features enabled, given the gobjc and GNUstep prerequisites, and whether the graphrag-server feature set you need compiles with the flags the README lists.
Editorial conclusion
Adopt graphrag-rs if you want a Rust-native GraphRAG pipeline and can accept the documented defaults (hash-fallback embeddings, pattern-based entity extraction) or run Ollama yourself for real embeddings. Do not adopt it if you need the hybrid architecture now, since the README states it is designed but implemented in Phase 3, or if you need a published crate version, since the quick start uses cargo install --path. Verify first that Rust 1.85+ and the wasm32-unknown-unknown target build cleanly on your machine, that ollama pull nomic-embed-text succeeds if you want semantic search, and that the graphrag index / graphrag ask round trip produces answers you consider usable on your own documents.
Community notes