Conversation Memory
Give your AI memory that carries across every conversation
DialogueDB stores what your AI needs to remember, scopes it to the right user, and makes it searchable by meaning. It lives in the same system as your conversations.
"Prefers dark mode, concise"One system
Memory and conversations in one database
When memory and conversations live in separate systems, they drift out of sync and your AI ends up with stale or incomplete context. DialogueDB stores both in the same database, so the context is always current.
Separate memory service
DialogueDB
What's different
Three differences from most memory tools
Three architectural choices that change what your memory contains and how your AI retrieves it.
You decide what matters, not the tool
Most memory tools decide what's worth remembering by extracting facts from conversations automatically, using their own model of importance. DialogueDB stores memory directly, so the contents reflect what you intended, not what an extraction pipeline guessed.
Search by meaning, not by key
Every memory is auto-vectorized at write time, so retrieval works by meaning instead of exact match. Your AI finds the right context for the current conversation without you tracking keys, so users don't repeat themselves and your retrieval logic stays simple as your data grows.
Per-user isolation built into the API
A namespace parameter scopes memory to individual users at the database level, not through application-layer filters. Multi-tenant apps stay safe by default, and cross-user leaks aren't a regression you can introduce by accident.
Built-in record fields
Tag, label, and annotate without designing a schema
Memory records include built-in fields for tags, human-readable labels, and immutable metadata. Filter by category, attach audit context, and trace a memory back to its source without adding a sidecar database or modeling a new table.
Tags are mutable for re-categorization. Metadata is immutable so it can stand in for an audit trail. Labels keep memory readable in dashboards and logs.
A memory record
Value
"User is allergic to peanuts"
Label
"Dietary restriction"
Namespace
"user_456"
Tags
Metadata
{ "source": "onboarding" }Auto-vectorized
Searchable by meaning at write time, no extra step
Store and retrieve
Store in one session, retrieve in the next
The first call stores a piece of context after a conversation ends. The second call retrieves it from a different session by meaning. No indexing step in between, no key to track, no schema to set up first.
import { DialogueDB } from "dialogue-db"
const db = new DialogueDB({
apiKey: process.env.DIALOGUEDB_API_KEY
})
// Session 1: store context from the conversation
await db.createMemory({
value: "User is allergic to peanuts",
label: "Dietary restriction",
namespace: "user_456",
tags: ["health", "dietary"]
})
// Session 2: retrieve by meaning
const { results } = await db.searchMemories(
"any dietary restrictions or allergies",
{ namespace: "user_456", limit: 5 }
)The memory written in the first session is searchable in the second one. There is no wiring between them and nothing to keep in sync.
Memory is available on every plan
Memory is included on every plan starting with the free tier. Plan limits apply to total memory count and storage. See pricing for specifics.
Any value, any type
Store strings, numbers, objects, or arrays
One call handles every value type. Whether you're storing a fact, a structured preference, or a list of feature flags, createMemory accepts it as written.
String
"User prefers concise responses"
Number
42
Boolean
true
Object
{ theme: "dark", fontSize: 16 }
Array
["feature_a", "feature_b"]
Tags categorize memories for filtering. Custom IDs enable deterministic access. Immutable metadata captures context you want to keep but never change.
Isolation in practice
Namespaces unlock multi-tenant patterns
The namespace parameter is more than an isolation guarantee. It's the primitive that turns one project into a multi-tenant memory system, where each user's data is scoped, queryable, and disposable on its own terms.
- Run a multi-tenant application from one project, with per-user memory automatically scoped.
- List or export every memory for a single user, useful for audits, data-portability requests, or debugging a session.
- Reset a user's AI experience by listing the memories in their namespace and deleting them, with no impact on anyone else.
- Write to a test namespace in development without polluting production memories.
- Honor data deletion requests by clearing memories in one user's namespace, without touching anyone else's history.
One project, isolated per user
namespace: "user_456"
namespace: "user_789"
Namespace isolation is enforced at the database level, not in application-layer filters.
Frequently asked questions
Common questions about memory in DialogueDB.
Memory in your conversation database
Store what matters, retrieve it by meaning, and keep every user's context scoped to them. Start on the free tier.