Auto-Vectorization
Semantic search for AI conversations, with nothing to set up
DialogueDB indexes every message, memory, and dialogue as it is saved, so search by meaning is available the moment your data is stored. No separate service to set up.
users struggling with onboarding
Support chat · 2 days ago
I've been stuck on the setup for an hour and can't figure out the next step.
Trial feedback · last week
The getting-started guide didn't match what I actually saw in the dashboard.
Product survey · yesterday
First-run experience was confusing, had to ask support to get going.
Where this usually breaks
Why adding semantic search to your own conversation storage is harder than it looks
Whether you build it yourself or wire in a managed tool, three things tend to go wrong.
Separate vector indexes drift from your data
When you build it yourself, you write the sync code. When you use a managed service, they handle sync but you can't see how. Either way, your conversation data and the search index fall out of step, and you find out during an incident. DialogueDB manages the sync between your conversation data and the vector index, so they cannot fall behind.
Retrieval choices stay hidden from you
Most managed memory tools make every decision about how content is indexed and ranked out of sight. Build it yourself and the same choices land on your team, where tuning becomes its own project. DialogueDB uses conversation-tuned defaults and shows what was indexed per message.
Bundled memory tools index a narrow surface
These tools usually only index extracted memories, not full messages or whole conversations. With a DIY setup, you decide what's indexable and most teams under-index by default. DialogueDB indexes messages, dialogues, and memories automatically, so anything in your conversation data is searchable.
How DialogueDB does it
Every message is searchable the moment it is saved
Every message you store is indexed for semantic search the moment it is saved. By the time your next request arrives, the message is searchable by meaning.
Search is ready by your next request
Indexing happens the moment a message is written, not on a scheduled job or a nightly batch. There is no delay baked in, so results are searchable seconds later.
Conversation-tuned defaults handle the indexing
How content is split, indexed, and ranked is configured for conversation data, so search results land well without tuning. Nothing on your team to maintain.
The vector index stays in sync without your code
Storing a message creates its vector. Deleting a message removes it. DialogueDB manages the entire sync between your conversation data and the vector index, so there is no pipeline for your team to build or monitor.
What happens when you write a message
Message written
dialogue.saveMessage() stores the message
Stream triggered
Database stream picks up the new record
Chunked and embedded
Content chunked, dense + sparse vectors generated
Index updated
Vector index updated, message is searchable
All managed by DialogueDB. No external pipeline for you to maintain.
See the code
Write, then search. Nothing in between.
No db.index(). No db.embed(). No db.sync(). The write and the search are the only two calls.
import { DialogueDB } from "dialogue-db"
const db = new DialogueDB({ apiKey: "your-api-key" })
// Create a conversation and save a message
const dialogue = await db.createDialogue()
await dialogue.saveMessage({
role: "user",
content: "I keep getting logged out after about ten minutes of inactivity"
})
// Search by meaning — vectorization already happened
const { results } = await db.searchMessages(
"user is having session timeout issues",
{ limit: 8 }
)
// Each result includes the message and a relevance score
for (const { item, relevance } of results) {
console.log(item.content, relevance)
}Auto-vectorization on every plan
Auto-vectorization and basic semantic search are included on every plan, starting with the free tier. Advanced search with keyword matching and additional ranking is available on Starter and above.
What you can search
Three object types, all vectorized automatically
Semantic search narrows by meaning first. Tags, metadata, and date ranges narrow by structure from there.
Messages
db.searchMessages()Find the exact turn where a user reported an issue, asked a question, or described a requirement.
Dialogues
db.searchDialogues()Whole conversations ranked by relevance. Find which conversation covered a topic without reading every thread.
Memories
db.searchMemories()Persistent facts and user knowledge stored across sessions, like user preferences or established context.
// Layer structure filters on top of semantic search
const { results } = await db.searchMessages(
"billing questions",
{
tags: { $in: ["support", "billing"] },
filter: { created: "last 30 days" },
namespace: "acme-corp",
limit: 10
}
)What's included
What automatic really means
All of this comes with the database, with no extra setup or configuration required.
Find conversations by meaning, even when the words do not match
Search for session timeout issues and find a message where a user wrote about being logged out, without relying on shared keywords.
Scope results by namespace for multi-tenant apps
Pass a namespace to keep one user, customer, or workspace isolated from another. Multi-tenant access control is built into the search, not your application code.
Layer tag, date, and metadata filters on top
Narrow semantic results to a tag, a date range, or any metadata field without giving up meaning-based ranking.
Search messages, dialogues, or memories from one call
Use the same search API across individual messages, whole conversations, or persistent memories.
See what was indexed per message
When a retrieval looks off, the index status, chunk count, and any failure reason are visible per message, so debugging is straightforward.
Results come ranked by meaning
Each match includes a relevance score, ordered strongest match first, so you can cut off at the threshold that fits your use case.
How the approaches compare
How DialogueDB compares
Building your own or wiring in a managed service both work. The case isn't that those are bad. It's that they're separate projects, and this isn't.
| Approach | Setup | Sync reliability | Chunking | What's searchable |
|---|---|---|---|---|
| Custom vector database setup | Separate account, index config, pipeline to build | Manual, drift is your problem | You decide | Whatever you index |
| Self-hosted vector database | Infrastructure to run and maintain | Better if managed carefully | You decide | Whatever you index |
| Managed memory service | Low | Usually automatic | Not configurable | Extracted memories only |
| DialogueDB | None | Automatic, no drift | Conversation-tuned defaults | Messages, dialogues, memories |
Frequently asked questions
Your conversations are searchable
from the first message
No separate search service to set up. No indexing code to maintain. Start free and search by meaning in minutes.