What happened when we ran it
Our sandbox installed LightRAG in 6 seconds, adding 85 packages and occupying 220 MB on disk. The build completed in another 2 seconds. Pytest was the break: after 163 seconds it stopped during collection with 60 errors. Nothing reached an executed test assertion, so the result was 0 passed, 0 failed, and 15 skipped. Pip-audit found 0 known vulnerabilities in the installed Python environment. Install and build were easy to reproduce; the repository's full test entry point was not.
This was commit 300d9df in an unprivileged Debian container with 3 CPUs and 6 GB of RAM. The checkout contained 1,043 files, about 367,169 source lines, and used 23.4 MB. The test log ended on modules for DOCX smart headings and validation, MinerU deletion variants, parser parameters, legacy extractors, and document-path normalization. It also recorded 1,321 warnings. That excerpt does not identify why collection failed, so blaming a missing package or a code defect would be guesswork. A team adopting LightRAG should preserve the complete log and establish its own known-good test command before upgrades.
Four storage roles make production an infrastructure job
A LightRAG deployment writes key-value data, vectors, graph data, and document status through four storage roles. During ingestion, a language model extracts entities and relationships from chunks. Queries can then use five modes: local, global, hybrid, naive, or the default mix, which combines graph and chunk retrieval. This is useful when the answer depends on connections across documents. For a narrow FAQ where one passage usually contains the answer, the graph work may buy little. Compare mix with naive retrieval on the same questions before accepting the extra extraction bill.
The convenient file-persisted defaults are explicitly limited to development and debugging. PostgreSQL, MongoDB, or OpenSearch can cover all four roles in production, while specialist deployments can combine systems such as Qdrant and Neo4j. That choice deserves early testing: our 220 MB Python installation says little about the databases, model weights, or corpus indexes a real deployment will add. Maintenance commands cover vector rebuilding, cache work, graph repair, and source conflicts, but backups remain your responsibility.
The embedding model is a migration decision
Changing one embedding model forces LightRAG to rebuild vectors for text chunks, entities, and relationships. The same model must be used while indexing and querying, and the README says LightRAG does not provide a re-embedding tool. Some backends also fix the vector dimension when tables are created. Choose an embedding model with the languages and dimensions you expect to keep, then treat a later change as a data migration rather than an environment edit. This constraint matters most after the corpus is expensive to parse and extract again.
Model configuration extends beyond embeddings. The workflow has four language-model roles for extraction, queries, keywords, and visual input. The README recommends a faster non-reasoning model for extraction and a stronger model for final answers. Reranking is optional, as are MinerU, Docling, visual processing, and local model serving. The package audit found 0 known vulnerabilities, but it cannot account for those separately operated services or the models downloaded after setup. Concurrency settings for files, parsing, embeddings, and model calls add another layer of capacity planning.
The REST server does not expose every useful control
LightRAG's server binds to 0.0.0.0 by default, so a new instance is reachable on every interface. The README tells operators to set an API key or account authentication before network exposure, and notes that Ollama-compatible routes stay open unless the whitelist is changed. This is a deployment requirement, not optional polish. The server also includes a Web UI, REST endpoints, and Docker Compose. Bind it to localhost during evaluation, then make the authentication and route policy explicit before adding a reverse proxy.
The API boundary has functional limits too. Issue #3603 reports that REST scan and upload routes bypass the legacy custom chunking callback because those routes always choose one of the built-in strategies. Issue #3706 describes no first-class way to attach a document's authoritative date to extraction and answer context. If temporal provenance matters, confirm the current API contract before indexing. Our 60 collection errors are a second reason to test the exact parser route rather than assuming every documented combination works on a fresh host. The README itself reserves some experimental capabilities for the SDK.
Active work does not remove scaling questions
LightRAG had 208 open issues and pull requests combined after an August 26, 2026 push. The latest release was v1.5.7rc2, published August 19, with fixes across parsers, graph handling, storage, API validation, and provider bindings. Nine CI workflow files, a Dockerfile, Compose configuration, a tests directory, and detailed deployment guides show sustained engineering work. The release-candidate label and the size of the open queue still argue for pinned versions and staged upgrades. Recent issue updates and merged fixes matter more here than the tag alone.
One open discussion, issue #1957, reports a custom deployment where adding a document took more than 20 minutes around 1,000 documents, 140,000 entities, and 160,000 relationships. That is one user's workload, not our benchmark, but it identifies a sensible test: measure ingestion as your own graph grows. Our run never reached those operations because pytest stopped after 163 seconds. LightRAG earns a pilot when graph retrieval improves your evaluation set enough to pay for that operational work; otherwise, ordinary vector retrieval is the simpler choice. Record indexing time at several corpus sizes instead of extrapolating from the first batch.