这是indexloc提供的服务,不要输入任何密码
Skip to content

[Feature Request]:Workspace-Level Document Isolation and Retrieval Separation #2373

@akash171198

Description

@akash171198

Do you need to file a feature request?

  • I have searched the existing feature request and this feature request is not already filed.
  • I believe this is a legitimate feature request, not just a question or bug.

Feature Request Description

Description

We are using LightRAG to support multiple business units (or multiple client workspaces) inside a single deployment. Currently, the platform does not provide a clear or enforced way to isolate documents by workspace/tenant. As a result, documents uploaded for one business can influence retrieval results of another business, causing cross-tenant data leakage.
To avoid this, we are forced to run completely separate LightRAG instances for each business, which increases operational overhead, maintenance cost, and complexity.
We would like to request a built-in, first-class feature to support workspace-level document and retrieval isolation, both in the backend APIs and in the UI.

What We Need (Clear Requirements)

  1. Workspace selection in the UI
    There should be a visible and mandatory Workspace selector in the LightRAG UI where a user chooses which workspace they are currently working in.
    Example: A dropdown or switch such as:
    Workspace: Client_A | Client_B | Client_C

  2. Workspace-scoped document uploads

When uploading documents through the UI or API:

  • A user should explicitly select the workspace they want to upload documents into.
  • LightRAG should internally store documents, vector embeddings, graph nodes, and metadata within that workspace only.
  1. Workspace-scoped retrieval / querying
    When running queries in the UI or using the API:
  • Retrieval should automatically happen only from the selected workspace.
  • Documents belonging to another workspace must not be retrieved unless explicitly configured.
  1. Strong backend enforcement
    Even if the UI is removed, the backend should enforce:
  • Workspace-specific storage partitions (directories, collections, tables, prefixes, etc.)
  • Workspace filtering at retrieval time
  • Isolation for vector DB, document store, graph DB, and document status tracking
  1. Documentation
    Clear documentation should explain:
  • How to use multiple workspaces
  • How documents are isolated at each storage backend
  • How to migrate from a single-workspace setup to multi-workspace
  • How developers should initialize and query with workspace context

Additional Context

Motivation / Use-Case (Revised)

  • Many organisations host multiple clients or internal teams on the same infrastructure.
  • To maintain data privacy and correctness, document ingestion and retrieval must be workspace-isolated.
  • Although LightRAG currently allows passing a workspace parameter at initialization, in practice the workflow still requires different instances to achieve true isolation.
  • A UI-level workspace selector plus enforced backend partitioning would enable LightRAG to be used in multi-tenant SaaS or enterprise scenarios without deploying multiple servers.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requesttrackedIssue is tracked by project

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions