nlqdb

Solve · Agent builders

How do I store and query my chatbot's conversation history?

If your chatbot needs to keep its conversation history and answer questions like 'messages per day' or 'most active users this week', give it a real database. nlqdb provisions Postgres from your first English goal and runs the GROUP BY in SQL — a vector store recalls one message, a database counts them all.

Teams building a chatbot or support assistant log every turn somewhere — but the moment a PM asks 'how many conversations did we have this week?' or 'which users send the most messages?', a transcript dumped in a JSON column or a vector store is the wrong shape. Vector memory (Mem0, Zep) recalls the most similar past message; it has no query planner, so an engagement rollup becomes the LLM doing arithmetic over search hits instead of a real GROUP BY.

The snippet that solves it.

> conversations grouped by day with a message count for each

What nlqdb does for this

  • Conversation turns are typed rows in Postgres, so 'messages per day' and 'average turns per session' run as SQL GROUP BY — not log math.
  • Ask the engagement question in English via MCP `nlqdb_query` or the `@nlqdb/sdk`; every answer returns rows plus the compiled SQL to audit.
  • Write turns with the deterministic `nlqdb_remember` tool (or a `POST /v1/run` INSERT) and report over the same database — no second store, no ETL.
  • Schema evolves in English: `"add a sentiment column to messages"` migrates the table; the diff is shown before apply.

Drop into any HTML page

<nlq-data goal="conversations grouped by day with a message count for each"></nlq-data>

The first engagement question a chatbot team asks — volume over time — is one English goal here, not a hand-written GROUP BY over a transcript table.

What this replaces

What nlqdb doesn't try to do here

  • No semantic search over message text — finding the most similar past message is a vector store's job (Mem0, pgvector); nlqdb answers the counting questions, not the similarity ones.
  • No ingesting your existing logging pipeline — nlqdb stores the conversation rows you write to it. If your transcripts already live in a Postgres or ClickHouse you run, connect it with the signed-in BYO connect verb and query it in place.
  • No built-in PII redaction or retention policy on message text — you choose what to write; anonymous DBs auto-sweep at 72h, authed rows persist until deleted.

Questions buyers ask

How is this different from giving my agent persistent memory?
Persistent memory stores the facts an agent learns so it can recall them later (see /solve/give-ai-agent-persistent-memory). This page is the raw conversation transcript plus engagement analytics over it — messages per day, most active users, turns per session. nlqdb is the same Postgres for both, so there's no second store to keep in sync.
Why can't a vector store answer 'how many conversations this week'?
A vector store returns the top-k most similar messages; it has no query planner. A count or a per-day rollup then becomes the LLM doing arithmetic over a list of search hits — a hallucination generator, not a GROUP BY. nlqdb runs the aggregation in Postgres and shows you the SQL it ran.
How do I get conversation turns into the database?
Write each turn with the deterministic `nlqdb_remember` MCP tool, or send a parameterised INSERT through `POST /v1/run`. Then ask engagement questions in English over the same table. The remember path builds the INSERT server-side, so the row shape stays a trust boundary, not LLM-guessed.
Can I see the SQL behind the engagement numbers?
Always — every answer returns the result rows plus the compiled SQL under a trace toggle, so you can verify the grain (per message vs per conversation) before trusting a dashboard number. nlqdb never hides the SQL behind the answer.

Where this pain shows up in public

Enduring discussion hubs where you can verify the theme without taking our word for it. We don't quote individual posts; we cite search-result and subreddit URLs that stay live as new threads land.

Try nlqdb in 30 seconds

No sign-in. The anonymous database lasts 72 hours; adopt it with one click if you keep it.

Start with a goal →

Looking at this from a different angle? Browse all solve pages or browse competitor comparisons.