You're building a SaaS product. Your AI needs to remember each of your thousands of users individually. How do you do that without spinning up a separate database per user?
The Naive Approach (Don't Do This)
One approach is to store everything in a shared pool and filter by user ID at query time. The problem: this is a privacy disaster waiting to happen. A bug in your filter logic could expose one user's memories to another. And semantically similar queries could retrieve memories from the wrong user.
The Right Pattern: external_user_id
The correct approach is to namespace memories at the storage layer. Every memory and every search is scoped to a specific external_user_id. The isolation is enforced at the database level, not in your application code.
// Alice's memory — stored with her email
POST /v1/memory/
{ "content": "Alice is on the Pro plan", "external_user_id": "alice@company.com" }
// Bob's memory — completely isolated from Alice
POST /v1/memory/
{ "content": "Bob is building a healthcare app", "external_user_id": "bob@company.com" }
// Search only returns Alice's memories
POST /v1/memory/search
{ "query": "What plan is the user on?", "external_user_id": "alice@company.com" }Using Email as the Identifier
We strongly recommend using the end user's email address as the external_user_id. It's naturally unique, human-readable in your dashboard, and directly connects memories to real users when you need to respond to GDPR deletion requests.
Scale Without Worry
This pattern scales to millions of users with no architectural changes. The vector database handles the indexing. The memory isolation is automatic. You just pass the right external_user_id and everything works.