- How is this different from giving my agent persistent memory?
- Persistent memory is the write side — the agent storing facts so it can recall them later (see /solve/give-ai-agent-persistent-memory). This page is the read side: running analytical reports — counts, top-N, averages per group — over what it stored. nlqdb is the same Postgres for both, so there's no second store to sync.
- Why can't my vector memory just answer "top 10 topics this month"?
- A vector store returns the top-k most similar rows; it has no query planner. An aggregation 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.
- What does the report query actually look like?
- You write the goal in English — 'count of facts the agent logged per category this month, highest first' — and nlqdb compiles it to SQL over the memory table, runs it, and returns the ranked rows. The compiled SQL shows under the trace toggle (`SK-WEB-005`) so you can verify the grain.
- Do I need a separate analytics database for this?
- No. The agent writes its memory rows to nlqdb's Postgres and reports over the same database — no ETL pipeline, no second connection string. Phase 2's workload analyser proposes a ClickHouse migration automatically if scan volume ever crosses the threshold, without an app-side rewrite.