39.5k stars · MIT · v1.5.7 (2026-09-02)
Entity-and-relationship graph over documents with local and global query modes — GraphRAG's structure at a fraction of the cost, stored in PostgreSQL.
▶Repo detailsthe review · specs · pros & cons · install
What it is
A retrieval system that extracts entities and the relationships between them from your documents, assembles them into a graph, and then answers questions at two levels: local, about a specific entity, and global, about themes across the whole corpus. It supports PostgreSQL, Neo4j, MongoDB and others as the graph and vector store, and ships a server with a web interface that draws the graph.
Why it matters
Edition 1 gave you GraphRAG and said honestly that it costs thousands of LLM calls per import; Edition 3 gave you BERTopic as the cheap default. This is the third position, and it is the one that changes the shape of the product rather than its price. Two things matter. The entity graph is a genuinely different view from the topic tree — who and what is being discussed and how they connect, rather than which clusters exist — and that is a second screen you could ship from the same import. And its incremental insertion means adding new messages extends the graph instead of triggering a rebuild, which is what makes "map this conversation as it grows" a feature rather than a wish. The PostgreSQL backend is the practical detail: the graph can live beside pgvector rather than in a Neo4j you would have to run, secure and back up separately.
- MIT, and the PostgreSQL storage backend keeps you on the one-database plan that pgvector and Procrastinate have already argued for
- Incremental insertion — new text extends the graph rather than forcing a full re-index, which is the expensive part of GraphRAG
- Local and global query modes map cleanly onto Grasppy's drill-in and its "summarise the whole thing" promise
- It still runs a model over every chunk to extract entities. Cheaper than GraphRAG is not the same as cheap — put LiteLLM in front of it before the first large import, not after the bill
- A fast-moving research project with a wide surface area, and documentation that assumes you already speak RAG
- You now hold three candidate engines for one job. The honest instruction is to run this against BERTopic over the same twenty conversations and delete the loser — two topic engines is two things to debug at three in the morning
And its incremental insertion means adding new messages extends the graph instead of triggering a rebuild, which is what makes "map this conversation as it grows" a feature rather than a wish.
The PostgreSQL backend is the practical detail: the graph can live beside pgvector rather than in a Neo4j you would have to run, secure and back up separately.
source venv/bin/activate pip install "lightrag-hku"