[Feature Request]: Analysis for document delete support approach

[gona-sreelatha]

Do you need to file an issue?

• I have searched the existing issues and this feature is not already filed.
• My model is hosted on OpenAI or Azure. If not, please look at the "model providers" issue and don't file a new one here.
• I believe this is a legitimate feature request, not just a question. If this is a question, please use the Discussions area.

Is your feature request related to a problem? Please describe.

I’m planning to extend GraphRAG to support delete operations by introducing a custom workflow.

Proposed Approach

1. Delete the target document.
2. Delete its associated text_units.
3. Remove references to those text_units from entities and relationships.

   •  If an entity/relationship has other text_unit references, update it accordingly.
     

   • If the entity/relationship is only linked to the deleted text_units, remove it entirely.
     

4. Re-run community generation and community summarization to ensure consistency.

Questions

1. Would this approach be sufficient to properly handle deletes?
2. Are there any pitfalls or edge cases I should watch out for?
3. Do you have any alternative suggestions or best practices for implementing deletes in GraphRAG?

I would deeply appreciate any inputs, suggestions, and thoughts from maintainers and community.
Thanks for your input!

@natoverse @AlonsoGuevara @darthtrevino

Describe the solution you'd like

No response

Additional context

No response

[natoverse]

I think you are probably over-complicating what you need to do. GraphRAG makes aggressive use of a cache, so re-running is essentially "free" if a dataset hasn't changed. Therefore, if you remove content from your input folder, re-running should just emit entities for all of the documents that are present, and will then re-run community generation and summarization anyway because the inputs to those processes will have changed. I think that means you can just delete your target document and re-run without needing to trace and remove any references.

The primary reason we haven't implemented document update/delete in our incremental approach (which is only additive) is essentially because we haven't figured out a way to do it more cheaply than this.

Hope this helps!

[gona-sreelatha]

Thank you for the clarification! @natoverse

My primary use case is running GraphRAG on large codebases, where repositories can be quite massive. I have seen great results with this lib and I have tried quite a few, thankyou for the lib!
While I understand that caching helps minimize redundant LLM calls, I’m still concerned about the practicality of re-indexing the entire repo whenever even a small change occurs — such as a single file, or relationships added / modified in a file

Even if LLM costs are avoided due to caching, the process itself can still feel time-consuming and computationally heavy, since it needs to validate caches and re-run community generation and summarization. Given that codebases typically change on a daily basis, I’m also worried about the repeated cost of recomputing communities and summaries so frequently.

In my case, I need the system to reflect the latest updates by atleast a day, so waiting to batch multiple changes before re-running isn’t really an option for me. Do you have any suggestions or recommended approaches for handling this kind of scenario more efficiently?

[ajaykumar9759k-crypto]

Thank you for the clarification! @natoverse

My primary use case is running GraphRAG on large codebases, where repositories can be quite massive. I have seen great results with this lib and I have tried quite a few, thankyou for the lib! While I understand that caching helps minimize redundant LLM calls, I’m still concerned about the practicality of re-indexing the entire repo whenever even a small change occurs — such as a single file, or relationships added / modified in a file

Even if LLM costs are avoided due to caching, the process itself can still feel time-consuming and computationally heavy, since it needs to validate caches and re-run community generation and summarization. Given that codebases typically change on a daily basis, I’m also worried about the repeated cost of recomputing communities and summaries so frequently.

In my case, I need the system to reflect the latest updates by atleast a day, so waiting to batch multiple changes before re-running isn’t really an option for me. Do you have any suggestions or recommended approaches for handling this kind of scenario more efficiently?

I exactly have the same need.
I want to do incremental indexing for the files updated on master while keeping database clean so that it doesn't affect the result.

[gona-sreelatha]

For anyone interested in some stats — I’m currently using GPT-4.1-mini and ran indexing on 175 input files, which cost approximately $7 in total.

When I re-ran the indexing (expecting cache hits) after deleting two files, the cost was around $1.30. Running an incremental update after adding a single new file costs only a few cents — roughly $0.02.

From my observations, the majority of token usage during reindexing comes from community summarization and text embedding API calls.