Feature/workspace isolation

[disillusioners]

Description

Adds workspace-based data isolation across all 13 LightRAG storage backends, enabling safe multi-tenant deployments where each LightRAG instance operates in its own isolated data space.

Every LightRAG instance can now be assigned an immutable workspace identifier. All data — entities, relations, documents, indexes — is namespaced under that workspace, preventing cross-tenant data access or collision.

Supports all 13 storage backends:

Category	Backends
Graph	NetworkX, Neo4j, Memgraph
Vector	FAISS, NanoVectorDB, Milvus, Qdrant
KV / Doc	PostgreSQL, MongoDB, Redis, OpenSearch, JSON KV, JSON DocStatus

Isolation strategy varies by storage type:

• Shared storage backends (Neo4j, Redis, PostgreSQL, etc.) — uses {workspace}:{namespace} prefix on entity/relation identifiers. Each workspace's data is isolated at the key/ID level within the same physical store.
• File-based backends (NetworkX, NanoVectorDB, FAISS, JSON KV, JSON DocStatus) — uses directory-based isolation via self.workspace path. Each workspace gets its own data directory.

Workspace lifecycle:

• Set at LightRAG(working_dir=..., workspace="tenant-a") construction time
• Immutable after creation — cannot be changed on an existing instance
• Strong input sanitization: path traversal prevention, character whitelist (a-z, 0-9, -, _), length limits

Administrators of server-based backends can leverage existing environment variable controls (e.g., WORKSPACE_ISOLATION, {BACKEND}_WORKSPACE) alongside this feature.

Related Issues

Changes Made

• Added workspace parameter to LightRAG constructor for multi-tenant data isolation
• Implemented workspace-based key namespacing ({workspace}:{namespace}) for shared storage backends (Neo4j, Memgraph, PostgreSQL, MongoDB, Redis, OpenSearch)
• Implemented directory-based isolation for file-based backends (NetworkX, NanoVectorDB, FAISS, JSON KV, JSON DocStatus)
• Added workspace input sanitization (path traversal prevention, character whitelist, length limits)
• Ensured workspace feature works with existing server-backend environment variable controls (WORKSPACE_ISOLATION, {BACKEND}_WORKSPACE)
• Ensured full backward compatibility — existing code without workspace continues to work identically

Checklist

• Changes tested locally
• Code reviewed
• Documentation updated (if necessary)
• Unit tests added (if applicable)

Additional Notes

Test coverage: 3 test files, 1,653 lines total:

File	Focus	Scenarios
test_workspace_isolation.py	End-to-end isolation across backends	11 scenarios
test_workspace_migration_isolation.py	PostgreSQL migration under isolation	Migration-specific
test_workspace_sanitization.py	Cypher injection & input sanitization	Security edge cases

Backward compatibility: Fully backward compatible. Internal separator differences between backends (: vs _) and empty-workspace normalization are preserved for compatibility.

Usage example:

# Each tenant gets an isolated LightRAG instance
rag_tenant_a = LightRAG(working_dir="./data", workspace="tenant-a")
rag_tenant_b = LightRAG(working_dir="./data", workspace="tenant-b")

# Data is fully isolated — no cross-contamination
rag_tenant_a.insert("Alice works at Acme Corp")
rag_tenant_b.insert("Bob works at Tech Inc")

# Queries return only the tenant's own data
rag_tenant_a.query("Who works where?")  # → Alice at Acme
rag_tenant_b.query("Who works where?")  # → Bob at Tech