Replies: 4 comments
|
I have this requirement. I am also developing a multitenant multiuser application. |
|
It appears that the development team is actively working on the upgrade to version 2, so I am reluctant to submit a PR right now. If version 2 doesn't contain something like this, I am prepared to rework the code for the new version. |
|
Even I am working on this part. If it's fine with you, can we talk about it, or maybe you can raise the request? I would love to test it out what you have built. |
|
The primary change was to lightrag_server.py with the addition of "class RAGInstanceManager". The code is on my fork at https://github.com/djrfree/LightRAG/tree/main-v1.4.13rc1/lightrag. Here is the summary from copilot:
Each workspace maintains completely separate:
RAGInstanceManager class handles all workspace lifecycle operations
Recommended settings by scale: Development: 10 workspaces, 30-min timeout |
Uh oh!
There was an error while loading. Please reload this page.
Executive Summary:
I have implemented a comprehensive workspace isolation layer on top of v1.4.10 (build 0272) to enable true multi-tenant operations. This architecture moves away from a single global state to a managed, per-request RAG instance model. It has been stress-tested using PostgreSQL (pgvector + Apache AGE) in a high-scale environment requiring a large number of independent workspaces.
Core Architectural Changes:
RAGInstanceManager:
A new management layer using asyncio double-check locking to ensure thread-safe, concurrent initialization of workspace-specific instances.
Intelligent Caching:
Implemented LRU (Least Recently Used) eviction and TTL-based cleanup to manage memory and database connection pools across "unlimited" potential workspaces.
Dynamic Routing:
Workspace selection is now malleable per-request via the LIGHTRAG-WORKSPACE HTTP header or request body parameters, overriding the server's default .env configuration.
Full-Stack Support:
Web UI: Added a persistent workspace selector in the settings panel (0272) that injects headers into all axios and fetch calls.
Integrations: Extended the Open WebUI tool with workspace valve configurations.
Critical Fixes Included:
Resolved PostgreSQL serialization issues where bytes/memoryview objects failed during JSON-compatible string conversion.
Corrected the paginated documents endpoint to use workspace-aware parameters and proper Pydantic field typing.
Fixed the pipeline status endpoint to retrieve context-specific RAG instances.
Discussion Goal:
I believe this architecture provides a production-grade foundation for LightRAG multi-tenancy. I would like to discuss:
All reactions