microsoft/graphrag: a graph-based RAG pipeline that is now in maintenance mode

What microsoft/graphrag solves that vector search does not

Standard retrieval-augmented generation splits documents into chunks, embeds them, and returns the chunks whose vectors sit closest to the question. That works when the answer lives inside one passage. It fails on questions like "what themes connect these incident reports" or "which suppliers appear in both the audit and the recall notice", because no single chunk contains the answer. The relationship is the answer, and it is spread across the corpus.

GraphRAG is built for that second class of question. The README describes it as "a data pipeline and transformation suite that is designed to extract meaningful, structured data from unstructured text using the power of LLMs." The output is not a vector index over chunks. It is a graph of entities and relationships, plus community summaries generated over clusters of that graph, which the query side then reads. The homepage frames the same idea as using knowledge graph memory structures to enhance LLM outputs.

The intended audience is narrow on purpose. You need a corpus of narrative text (reports, filings, transcripts, research notes) where the interesting signal is who relates to whom, and you need the budget to run an LLM over every chunk during indexing. The README carries an explicit warning that indexing can be an expensive operation and tells readers to start small. That warning is the most useful sentence in the repository for anyone deciding whether to adopt it.

The indexing pipeline: chunks in, communities and reports out

The architecture visible in the repository is a staged pipeline, not a single call. Text is split into chunks, an LLM extracts entities and relationships from each chunk, those extractions are merged into a graph, the graph is clustered into communities, and an LLM writes a summary report for each community at several levels of granularity. Query time then has two modes: local search, which walks outward from entities near the question, and global search, which reads the community reports to answer broad, corpus-level questions.

The practical consequence is that cost scales with corpus size at index time, not at query time. Every chunk passes through an LLM at least twice (extraction, then summarization), so a corpus that is cheap to embed can be expensive to graph. This is also why the pipeline is modular: the repository is a monorepo with a packages/ directory and a pyproject.toml whose project name is graphrag-monorepo, so the extraction, storage and query pieces are separable rather than one monolith.

The repository also ships a unified-search-app/ directory and a docs/ tree built with mkdocs.yaml. That layout tells you the project expects you to read documentation before running it. The README says as much: it recommends the command line quickstart and states that using GraphRAG with your data out of the box may not yield the best possible results, pointing to a prompt tuning guide.

How to install graphrag and run a first index

The README does not inline install commands; it points to the command line quickstart in the documentation. What the repository does confirm is the Python requirement: pyproject.toml declares requires-python = ">=3.11,<3.14". Anything outside that range, including Python 3.10 and 3.14, is outside what the project declares support for.

The package is published on PyPI under the name graphrag, which is the name the README's badge links to. A standard install is:

pip install graphrag

After installing, the documented entry point is the graphrag command line. The README's versioning note gives the initialization command explicitly, including the --root and --force flags:

graphrag init --root [path] --force

That command writes a configuration file and a set of prompt files into the target directory. The README warns that --force overwrites your configuration and prompts, so back them up if you have edited them. Expect to see a settings file plus prompt templates you can edit, which is where prompt tuning happens.

Once configuration exists, you supply input text and run indexing against that root. The README does not print the indexing command in the text available here, so check the command line quickstart page for the exact subcommand before running it. Start with a handful of documents rather than the full corpus, because the README states indexing can be expensive and advises starting small.

The maintenance-mode warning is the biggest constraint

The README opens with a warning block stating that GraphRAG is a research project, that it is "largely in maintenance mode, and won't be accepting new PRs or implementing new features", and that bug fixes and dependency updates will continue, particularly for CVEs. That is unusually direct for a Microsoft repository, and it should shape the adoption decision more than any architectural detail.

The last push was on 2026-08-21, and the most recent release listed is v3.1.2 on the same date, so the maintenance is real maintenance rather than abandonment. But maintenance mode means the roadmap is closed. If your use case needs a feature that does not exist today, you are implementing it yourself or forking.

There is a second constraint in the versioning note. The README instructs readers to always run graphrag init --root [path] --force between minor version bumps to pick up the latest config format, and to run a provided migration notebook between major version bumps if they want to avoid re-indexing prior datasets. Since indexing is the expensive step, a major version bump can mean paying for the whole corpus again unless the migration path works for you. Pin your version and read breaking-changes.md before upgrading.

A third constraint is scope. The README states plainly that the code "serves as a demonstration and is not an officially supported Microsoft offering." Plan accordingly: no support contract follows from the Microsoft name.

When graphrag is the wrong tool

If your questions are answered by a single passage, GraphRAG is overkill. You will pay for entity extraction and community summarization across the entire corpus to answer questions that a chunk embedding index handles in milliseconds. The README's own framing supports this: it is a research project exploring functional use of graphs to form targeted context, not a drop-in replacement for every retrieval layer.

If your corpus changes constantly, the economics get worse. Because the graph and its community reports are built in a batch indexing pass, a corpus that shifts hourly means frequent re-indexing and frequent LLM spend. There is no incremental update story documented in the repository.

If you need a supported product with a roadmap, this is the wrong choice for a different reason. The README states the project will not accept new PRs or implement new features and is not an officially supported Microsoft offering. Teams that need vendor accountability should treat GraphRAG as a reference implementation to learn from rather than a dependency to build on.

Finally, if you cannot tune prompts, results will disappoint. The README states directly that out-of-the-box use with your data may not yield the best possible results and strongly recommends fine-tuning prompts. That is an ongoing task, not a one-time setup step.

How graphrag differs from LangChain and from plain RAG

LangChain is a general framework for composing LLM applications: you assemble chains, retrievers, tools and memory from building blocks, and retrieval is usually vector similarity over chunks. GraphRAG is not a framework in that sense. It is an opinionated pipeline with a fixed shape (extract, cluster, summarize, query) and a command line that runs it. If you want to choose your own retriever topology, LangChain gives you that freedom and GraphRAG does not.

The comparison with plain RAG is the one the project itself invites. Vector RAG answers by proximity: the nearest chunks to the question are stuffed into the prompt. GraphRAG answers by structure and by precomputed summaries. For a question like "what are the main themes in this corpus", vector RAG has no good chunk to retrieve, while GraphRAG's community reports were written for exactly that query shape. For a question like "what is the refund window", the graph adds cost and latency without adding accuracy.

The graph store question comes up often, and it is worth being precise: the repository does not document a Neo4j backend, so treat any assumption that GraphRAG requires or ships with Neo4j as unverified. The pipeline's storage layer is configurable through the settings file that graphrag init writes, and that file is the place to check what backends your version supports.

Licence, upgrade cost and what maintenance mode means for a fork

The repository is MIT licensed. In practical terms that permits commercial use, modification and redistribution provided the copyright notice and permission notice are preserved. It also means there is no copyleft obligation forcing you to publish your own changes. This is not legal advice; read LICENSE in the repository and involve counsel if the deployment matters.

The upgrade cost is the part teams underestimate. The README's own instructions require running graphrag init --root [path] --force between minor version bumps, which overwrites configuration and prompts. If you have invested in prompt tuning, which the README strongly recommends, every minor upgrade forces you to reapply that tuning or back it up first. Major bumps may require the migration notebook to avoid re-indexing, and the README does not document rollback if a migration goes wrong.

Because the project is in maintenance mode, forking is a legitimate plan rather than a last resort. The MIT licence allows it, the monorepo layout under packages/ keeps components separable, and DEVELOPING.md exists for people working on the code itself. The honest trade-off: you inherit the CVE fixes the maintainers continue to ship, but you own every feature request from that point forward.

Editorial conclusion

Adopt microsoft/graphrag if you have narrative text where answers depend on relationships spread across many documents, and if you can pay for the LLM calls an index build requires. Do not adopt it as a general-purpose RAG framework for a single FAQ corpus, and do not expect new features: the README states the project is largely in maintenance mode and will not accept new PRs or implement new features, while bug fixes and dependency updates continue. Before committing, verify first that your Python version falls inside the >=3.11,<3.14 range declared in pyproject.toml, and run graphrag init --root [path] --force against a small sample to see the generated config and prompt files before you index anything large.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes