Multi-Tenant AI Architecture
Multi-tenant AI
data isolation
Cross-tenant data leaks shouldn't depend on whether you remembered the right query filter. DialogueDB isolates at the data model so the bug is impossible by design.
The problem
Multi-tenancy in AI is harder than it looks
Any AI product serving more than one customer has to solve this. A single cross-tenant data leak can derail an enterprise sale or cost you trust with everyone else.
Metadata filters have silent failure modes
When isolation depends on adding the right filter to every query, a single missed WHERE tenant_id = ? clause leaks data across customers. These bugs pass tests and surface in production.
Retrofitting isolation means rewriting queries
Adding multi-tenancy after the fact means auditing every query path in your AI assistant. One missed code path and you have a cross-tenant data exposure during your next security review.
Auditing per-customer AI activity is impossible
When conversations are mixed in a shared store, answering "what did the AI say to customer X?" requires filtering through everyone's data. Compliance and security reviews stall.
How DialogueDB solves it
Isolation at the data model, not the query
DialogueDB enforces isolation at two levels, project and namespace. Both run at the database partition key, not as application-layer filters that get accidentally omitted.
Project-level isolation
Each API key is scoped to a single project. Data cannot be accessed across projects, even with a bug in your application code.
Namespace isolation
Within a project, the namespace field partitions data per tenant or end user. All queries are automatically scoped. If you create a resource with a namespace, you must provide the same namespace to access it. Omitting it returns a not-found error, not someone else's data.
Database-level enforcement
Isolation is enforced at the database partition key level. Namespace and project ID are embedded in every partition key, so the database engine itself prevents cross-tenant access. No application-layer filter to forget.
How data is partitioned
API Key → Project A
namespace: "acme-corp"
Dialogues, messages, memories
PK: DIALOGUE#acme-corp#proj_a
namespace: "globex-inc"
Dialogues, messages, memories
PK: DIALOGUE#globex-inc#proj_a
Different partition keys, no query can cross the boundary
API Key → Project B
Completely separate data
Different API key, different project, different partition space
See the code
Tenant isolation in a few lines
Create a customer namespace, scope all queries to it, and let the database enforce isolation without custom middleware or query wrappers.
import { DialogueDB } from "@dialoguedb/client"
// API key is scoped to your project. Isolation starts here.
const db = new DialogueDB({ apiKey: "your-project-api-key" })
// Each customer gets a namespace. Data is partitioned at the DB level.
const tenantId = "acme-corp"
// Create a conversation scoped to this tenant
const dialogue = await db.createDialogue({
namespace: tenantId
})
await dialogue.saveMessage({
role: "user",
content: "Show me our pipeline metrics"
})
// Search only returns results from this tenant's namespace.
const { results } = await db.searchMessages("pipeline metrics", {
namespace: tenantId
})
// List dialogues. Only this tenant's conversations are returned.
const { items } = await db.listDialogues({
namespace: tenantId
})
// Delete a tenant's data. Cascades to all dialogues, messages, and memories.
await dialogue.delete()How this compares
How multi-tenant approaches compare
Building this yourself or using a general-purpose vector database with metadata filters are options. Both leave isolation up to your application code. Here's how they compare.
| DialogueDB | Postgres + pgvector + custom code | Vector DB + metadata filters | |
|---|---|---|---|
| Tenant isolation | Enforced at database partition key | Application-layer WHERE clauses | Metadata filter on every query |
| Failure mode | Query physically cannot cross namespaces | Missing filter returns wrong tenant's data | Missing filter returns wrong tenant's data |
| Setup time | Minutes. Get API key, pass namespace | Weeks. Schema, RLS, vector indexing, testing | Days. Collection setup, filter testing |
| Conversation features | Messages, threads, state, memories, search built in | Build from scratch | Vectors only. No conversation model |
| Audit capability | Events emitted for all operations | Build your own logging | Varies by provider |
| Operational burden | Fully managed | You manage everything | Managed vectors, but you build the rest |
Built for security reviews
What you can show your security team
Multi-tenant AI products stall in security review when they can't demonstrate data isolation guarantees. Here's what DialogueDB gives you out of the box.
Partition-level isolation
Namespace isolation enforced at the database partition key, not an application-layer filter.
Full audit events
Events emitted for all entity operations: creation, modification, and deletion.
Hard delete with cascade
Deleting a project permanently removes all associated dialogues, messages, and memories.
Immutable dialogue mode
Lock conversations for audit trails that can't be tampered with after the fact.
IP whitelisting
Restrict API access to trusted networks only. Available on Pro and Business plans.
No secondary data use
Customer data is never used for model training or any other secondary purpose.
Start building with the free tier
The free tier includes full API access with namespace isolation, semantic search, and conversation management. No credit card required. Upgrade when you're ready to scale.
Frequently asked questions
Common questions about multi-tenant isolation in DialogueDB.
Build multi-tenant AI without
writing isolation from scratch
Namespace-level isolation, audit events, and compliance, handled by the database, not your application code.