- 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 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.