39.5k stars · MIT · v1.5.7 (2026-09-02) · Track this in Scout
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.
What it is good for. Edition 1 covered GraphRAG and said honestly that it costs thousands of LLM calls per import; Edition 3 covered BERTopic as the cheap default. This is the third position, and it is the one that changes the shape of a 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 a drill-in interface and a "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.
pip install "lightrag-hku"
