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:

  1. Add database indexes:

  1. Use cache-based memory:

  1. 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


Need Help? Join the BoxLang Discord or check the GitHub Discussions for community support.

Last updated