Search & Retrieval
Find the right message by
meaning and by exact term
One query searches every message by meaning, with exact-term matching layered on. Narrow by namespace, tags, dates, and metadata in the same call. No separate search service to run.
problems exporting data
The CSV export keeps timing out on large projects.
How do I pull my report into a spreadsheet?
Is there a way to download everything as one file?
Where search usually falls short
One kind of matching is
never enough for conversations
Conversations mix loose phrasing with exact terms like error codes and product names. Pick one search method and you miss half of what you were looking for.
Keyword search misses the meaning
A search for "logout" never finds the user who wrote "my session expired." When people describe the same problem in different words, exact matching leaves the right message buried. DialogueDB matches by meaning first, so wording does not have to line up.
Meaning-only search misses exact terms
Semantic search alone can drift past an error code, an order ID, or a product name that has to match exactly. DialogueDB layers exact-term matching on top of meaning, so a literal string still lands when it matters.
Filtering means a second system
Narrowing by tenant, date, or a status field usually means bolting a separate filter layer onto your search, or pulling everything back and filtering in your app. DialogueDB takes namespace, tags, dates, and metadata in the same search call.
Inside a single query
Meaning and exact terms, in a single query
You describe what you are looking for in plain language. DialogueDB matches by meaning, adds exact-term matching alongside it, applies your filters, and returns results ranked by relevance. All from one call.
Semantic first, so wording does not have to match
Your query is compared by meaning against every message, dialogue, and memory. The right result surfaces even when it shares none of the same words.
Exact-term matching layered on top
The same query also matches literal terms, then merges those results with the meaning matches. Error codes, IDs, and product names land exactly, with no separate search to run.
Filters narrow the same call
Namespace, tags, metadata, and date ranges narrow the results without giving up meaning-based ranking. There is no second query and no post-filtering in your app.
One query, two kinds of matching, merged
Your query
exporting data
By meaning
finds "download as a file"
By exact term
finds "CSV export"
Merged and ranked
by relevance
Filters narrow the merged results in the same call.
The whole search
Query, filters, ranked results, in one call
No query language to learn, no index to configure, no search service to run.
One call does all three, whichever object you search.
Search that stays in sync with your data
Meaning, exact terms, and filters in a single call, with no separate search system to keep aligned as your conversations change.
Filters built in
Narrow by structure,
keep the ranking by meaning
Every filter rides on the same search call. Combine them freely to
scope results to the slice you care about.
Each filter compounds, narrowing the same query without a second call.
Namespace
Scope a search to one user, tenant, workspace, or account. Retrieval stays inside that partition, so one customer never sees another's messages.
Tags
Filter by broad categories like support, billing, or feedback. Operators match any tag, require every tag, or exclude tags outright.
Metadata
Filter on structured fields you control, like tier, region, status, or priority. Match values, match a list, or compare numbers with greater-than and less-than operators.
Dates
Filter by created or modified time. Use natural phrases like "last 30 days" or "March 2025", or exact ISO boundaries, with a timezone for where the day starts.
Search across all of it
Messages, dialogues, or memories, from one API
Pick the object that fits the job. The same query, filters, and ranking apply to each.
Messages
db.searchMessages()Find the exact turn where a user reported an issue, asked a question, or gave you the wording you need to quote.
Dialogues
db.searchDialogues()Whole conversations ranked by relevance, with supporting message evidence, so you can find where a topic came up without reading every thread.
Memories
db.searchMemories()Durable facts and user context stored across sessions, like preferences, constraints, and prior decisions.
// Search works well as a tool for an LLM agent:
// the model writes the query, you enforce the scope
const { results } = await db.searchMemories(
"notification preferences and timezone",
{
namespace: "user_456",
tags: { $nin: ["expired"] },
limit: 5
}
)
// Feed the retrieved context back to your model
const context = results.map((r) => r.item.content)How the approaches compare
One call versus a search stack you assemble
Each of these can be made to work. The difference is how many moving parts you own to get meaning, exact terms, and filters in the same result.
| Approach | Matches meaning | Matches exact terms | Filters | Setup |
|---|---|---|---|---|
| Keyword search in your database | No | Yes | Your queries | Already there |
| Vector database on its own | Yes | Weak on exact terms | Metadata you model | Account, index, pipeline |
| Bolt-on search service | Sometimes | Yes | Its own filter layer | Separate system to sync |
| DialogueDB | Yes | Yes, layered on | Namespace, tags, metadata, dates | None, one call |
Frequently asked questions
Search built into the database
your conversations already live in
No search service to run. No query language to learn. Start free and search your conversations in minutes.