Adding Workspace Support to LinghtRAG Server

[danielaskdd]

Background

• Support multiple document sets(Workspace) at one server
• Create and destroy document set easy and quick
• Temporary or private document set
• Single file RAG
• Ollama models emulation for multiple document sets
• Act as a Tool(MCP Server) to AI agent with multiple document sets

Challenge

• API Compatible
• Minimize UI changes at transition
• Method of storage isolation for each storage implentation
• Cache isolation
• Parallel document processing for difference document sets
• LLM sessions reserved for query to avoid frontend blockage

[ParisNeo]

Hi there.
Good idea.
This would mean a substantial upgrades.
And it won't be stable right away, so I suggest creating a new branch on which we can start this work.

We will need alot of changes.
We need to add a new storage to store user credentials and make a robust and secure architecture.

[niallam22]

Alternative Approach: API Key-Bound Collections

Background

Utilize the existing workspace field already present in database tables (I have only checked postgres)
Map collections to API keys rather than user credentials
Maintain backend service model with simpler authentication requirements

Benefits

Minimal schema changes (only needs a collections-to-API-key mapping table)
No need for user credential management within LightRAG
Preserves LightRAG as a backend service that can be integrated with any authentication system

Implementation Strategy

Create a lightweight collection management layer that maps collection IDs to workspaces
Extend API endpoints to accept collection ID as a parameter
Add validation to ensure collections are only accessible by their associated API key

Challenges Addressed

API Compatible: Extends existing API with minimal breaking changes
Minimize UI Changes: UI only needs to pass collection ID parameter
Storage Isolation: Uses existing workspace field in all tables

This approach would require significantly less architectural change than implementing a full user credential system, while still providing robust multi-document set capabilities. It maintains LightRAG as a flexible backend service that can be integrated with various frontend authentication systems rather than building that directly into the core.

[danielaskdd]

Support rapid creation of temporary Workspaces of previously indexed files, by utilizing LLM caching, and maintain document chunks. This means the creation process will be quick.

[waiwaiwai27]

may be adding users and groups.
different userr could be in different groups. using groups to access different workspace.

[georgewangchn]

All storage systems, including vector databases and graph databases, should include a kb_id attribute. This field must be passed in all storage and query operations to ensure data isolation across different knowledge bases.

[xuhewei98]

Consider adding an OCR module similar to the one in RAGFlow to parse non-text data such as images and tables

[danielaskdd]

LightRAG already support using Docling as file extractor.

[apiipc]

how to use docling

[danielaskdd]

By setting the environment variable:

DOCUMENT_LOADING_ENGINE=DOCLING

but this is deprecating as it causes the server stuck when docling is running.

[apiipc]

so is there any way i can sort the documents in light rag by topic,
or create workspace for each document content

[danielaskdd]

Currently, you launch multiple LightRAG Server Instances, whereas each instance hosting it's own workspace.

[BireleyX]

I hope this feature gets added soon! I'm currently running 2 instances of Lightrag to separate common data from user-specific data.
And my user-specific data is limited to one-user at a time for now.

Would it be feasible to implement an interim solution by adding a file_path filter in QueryParam? I think this will be much easier than using the ID list as filter. I can easily separate the source file folders for my common files and per-user files. When a query is made, I can place the root path as filter in the lightrag.query method to only include context from documents with file_paths containing the filter string.
I think this can meet the intended use of data separation for the meantime.

[danielaskdd]

LightRAG heavily relies on entity and relation summaries to answer queries, which cannot be filtered by file_path.

[bastianwegge]

Huge thanks to the team around LightRAG so far, these features and especially the single-doc-RAG sound very promising.

We have implemented a multi-topic (multiple instances of LightRAG) similar to the one described here using the existing LightRAG functionality. I have pasted a snippet in issue 1513.

IMHO LightRAGs concern should NOT be user-auth and IMHO the LightRAG web-ui is already a great start to kick new projects off of it. Addressing Cache isolation would bring huge benefits, as this is the main reason I'm back here searching discussions / issues.

[danielaskdd]

The completion of PRs #1743 and #1941 has successfully established workspace isolation across all storage components. This work lays a critical foundation for the upcoming multi-workspace support in the LightRAG Server.

[apiipc]

[image: Screen Shot 2025-10-15 at 13.54.08.png] how to speed up data query, my AI angent querying extract from "thongtu" knowledge takes a long time, how to make it faster - is it due to the configuration in render.com - can i export data from processed light rag to postres

…

On Wed, Oct 15, 2025 at 1:45 PM Daniel.y ***@***.***> wrote: Currently, you launch multiple LightRAG Server Instances, whereas each instance hosting it's own workspace. — Reply to this email directly, view it on GitHub <#1016 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BYVIAJ6CJN6XZRFDMR4SG2T3XXUQTAVCNFSM6AAAAABYQNRX2OVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTINRYGM3DIMI> . You are receiving this because you commented.Message ID: ***@***.***>

[Mobious]

I'd be interested in hearing how work on multi-workspace support in a single server instance is going. I'd very much like to use LightRAG with my project, but the current lack of this feature is a blocker as running a new server instance for every single workspace that end-users want to create isn't scalable.

[Varming73]

Out of curiosity: Would that mean that each virtual workspace (or domain, I don't know the right term) would have a separate knowledge graph AND that there also is a knowledge graph spanning the whole real workspace? Am asking as I've previously considered adding this to a different project (have refocused on LightRAG now), which could be really powerful - but complex if for example you have multiple users on the same instance and not all users may access all information.

And thanks to the team for this great project, especially the continued development - thanks!

[danielaskdd]

Each workspace constitutes an independent knowledge graph (KG). Constructing a unified global KG comprising multiple workspaces is currently impractical due to efficiency constraints and would require rebuilding from scratch. Although this reconstruction can be significantly accelerated by leveraging LLM caches within individual workspaces. However cross-KG queries across multiple knowledge graphs are still feasible.

[danielaskdd]

PR #2369 has resolved an issue where a single service created multiple LightRAG instances, each associated with a distinct workspace. This marks a significant advancement toward enabling dynamic workspace switching in the LightRAG Server.

[danielaskdd]

Issue #2373 outlines a specific multi-workspace use case.

[sillydong]

Drafted a PR to implement the multi-workspace lightrag server, check it out here #2445