When to use it

lightrag-agensgraph is for teams that want a turnkey graph-RAG engine — point LightRAG at documents and it builds the knowledge graph and answers questions — with the whole pipeline (graph, vectors, key-value, and document status) stored in one AgensGraph database.

Good fits

• Question answering across many documents. LightRAG’s dual-level retrieval combines entity-centric and relationship-centric context, so it handles questions that span documents better than plain vector RAG. Choose a mode per query: naive, local, global, hybrid, or mix.

• Knowledge bases that grow over time. Ingest documents incrementally; the document-status pipeline tracks each one, deduplicates re-submissions, and merges entities that recur across documents. For a large one-off load, bulk_ingest() rebuilds the vector indexes once at the end instead of inserting into them record by record.

• Multi-tenant deployments. Give each tenant its own workspace so independent knowledge bases share a single database with no data leakage.

• Curated graphs. Merge, edit, and delete entities, relationships, and whole documents as your source data changes.

How it compares

• Pick LightRAG when you want an opinionated graph-RAG engine and don’t need to build a general application framework around it.

• Pick cognee for a broader memory layer with more search modes (chain-of-thought, summaries, code graphs, ontology-typed extraction).

• Pick LangChain or LlamaIndex when you need full control of the retrieval pipeline inside one of those frameworks.

Consider an alternative when

• You need bespoke retrieval logic or tight framework integration — a LangChain or LlamaIndex build gives you more control.

• You want an agent to drive AgensGraph through tools — use the MCP servers.