Multi-Tenant Memory Guide
Enterprise guide to implementing multi-tenant memory isolation in BoxLang AI applications
This guide covers implementing secure, isolated memory for multi-user and multi-conversation applications using BoxLang AI's built-in multi-tenant support.
📋 Table of Contents
📖 Overview
Multi-tenant memory isolation enables:
🏗️ Multi-Tenant Isolation Architecture
👥 Per-User Isolation: Separate conversations for each user
💬 Per-Conversation Isolation: Multiple conversations per user
🔒 Data Security: Automatic filtering prevents data leakage
🏢 Enterprise Scale: Shared infrastructure with isolated data
📊 Analytics: Track conversations by user/conversation identifiers
Why Multi-Tenant Memory?
Without multi-tenant isolation, all users share the same conversation history:
With multi-tenant isolation, each user gets isolated memory:
🎯 Core Concepts
👤 UserId - User-Level Isolation
The userId parameter isolates conversations at the user level:
Use cases:
Single conversation per user
User-specific context retention
Customer support with user history
Personal AI assistants
💬 ConversationId - Conversation-Level Isolation
The conversationId parameter enables multiple conversations per user:
Use cases:
Multiple chat windows
Topic-based conversations
Ticket-based support systems
Project-specific contexts
Combined Isolation
Use both userId and conversationId for complete isolation:
This provides:
User isolation: User A can't see User B's conversations
Conversation isolation: User A's chat1 is separate from their chat2
Complete privacy: Each conversation is fully isolated
🔧 Implementation Patterns
Pattern 1: Single Conversation Per User
Simplest pattern - one conversation per user:
Pattern 2: Multiple Conversations Per User
Enterprise pattern - users have multiple concurrent conversations:
Pattern 3: Hierarchical Isolation (Organization → User → Conversation)
Complex enterprise pattern with organization-level isolation:
Pattern 4: Role-Based Memory Switching
Different memory types based on user roles:
Memory Type Strategies
Standard Memory Multi-Tenancy
All standard memory types support multi-tenant isolation:
Windowed Memory
Isolation method: In-memory arrays per userId/conversationId combination
Summary Memory
Isolation method: Summaries stored per userId/conversationId
Session Memory
Isolation method: Composite session key (key + userId + conversationId)
File Memory
Isolation method: Separate JSON file per userId/conversationId
Cache Memory
Isolation method: Composite cache key (key + userId + conversationId)
JDBC Memory
Isolation method: Database columns with WHERE filtering
Table structure:
Vector Memory Multi-Tenancy
All 11 vector memory providers support multi-tenant isolation:
BoxVector (In-Memory)
Storage: Metadata with in-memory filtering
Chroma
Storage: Metadata with $and operator filtering
PostgreSQL (pgvector)
Storage: Dedicated VARCHAR(255) columns with composite index
MySQL (9+ Native Vectors)
Storage: Dedicated VARCHAR(255) columns with composite index
TypeSense
Storage: Root-level fields with := filter syntax
Pinecone
Storage: Metadata with $eq operators
Qdrant
Storage: Payload root-level fields with match filters
Weaviate
Storage: Properties root-level with GraphQL Equal operator
Milvus
Storage: Metadata with filter expressions
Hybrid Memory
Storage: Delegates to underlying vector provider (Chroma in this example)
Security Considerations
1. Always Validate User Identifiers
Never trust client-provided userId/conversationId without server-side validation:
2. Use Session-Based UserId
Always derive userId from authenticated session:
3. Implement Authorization Checks
Verify user has permission to access specific conversations:
4. Sanitize Identifiers
Prevent injection attacks by sanitizing userId/conversationId:
5. Log Access for Auditing
Track who accesses which conversations:
6. Implement Rate Limiting
Prevent abuse by limiting conversation access:
Performance Optimization
1. Use Appropriate Memory Types
Choose memory types based on scale:
2. Index Database Columns
For JDBC and vector memory, ensure proper indexing:
3. Implement Caching
Cache memory instances to avoid repeated creation:
4. Cleanup Inactive Conversations
Periodically remove old conversations:
5. Use Connection Pooling
For database-backed memory, configure connection pooling:
Enterprise Patterns
Pattern 1: Multi-Organization SaaS
Isolate by organization → user → conversation:
Pattern 2: Customer Support Ticketing
Map conversations to support tickets:
Pattern 3: Departmental Isolation
Separate conversations by department:
Migration Guide
Migrating from Non-Multi-Tenant Memory
If you have existing non-multi-tenant memory implementations:
Step 1: Identify Current Usage
Step 2: Add UserId Parameter
Step 3: Update Existing Data
For database-backed memory (JDBC, Postgres, MySQL):
Step 4: Update Application Code
Troubleshooting
Issue: Users Seeing Other Users' Conversations
Symptoms:
User A sees User B's conversation history
Conversations mixing between users
Solution:
Issue: Conversations Not Isolated Within User
Symptoms:
User's different chat windows share history
Multiple conversations bleeding together
Solution:
Issue: Poor Performance with Many Users
Symptoms:
Slow memory retrieval
Database queries timing out
Solutions:
Add database indexes:
Use cache-based memory:
Implement memory pooling:
Issue: Memory Leakage Between Tenants
Symptoms:
Data from other users occasionally appears
Intermittent cross-contamination
Solution:
Issue: Export/Import Losing Tenant Information
Symptoms:
Imported conversations lose userId/conversationId
Restored memory shows wrong owner
Solution:
See Also
Memory Systems Guide - Standard conversation memory
Vector Memory Guide - Semantic search with isolation
Agents Documentation - Using memory in agents
Security Best Practices - Application security
Examples - Complete working examples
Need Help? Join the BoxLang Discord or check the GitHub Discussions for community support.
Last updated