1 · Remember
nlqdb_remember({
category: "user_preference",
content: "prefers concise replies",
user_id: "u_412"
})→ { id: 4129, ok: true }
The row lands in agent_memory — typed columns, not
an opaque vector blob.
Memory your agents can GROUP BY.
Give your agent a real database as its memory — typed rows it writes as it learns, queried in English. Not the top-k a vector store returns.
Spin up a database from a sentence.
Anonymous — no sign-in. Your DB lives 72h; sign in (always free) to keep it.
Install in your agent.
- Claude: Settings → Connectors → Add custom connector — paste the URL.
- Windsurf: Cascade → MCPs → Configure, or ~/.codeium/windsurf/mcp_config.json.
- Zed: Agent Panel → Add Custom Server, or ~/.config/zed/settings.json.
Anonymous — the configs ship with the
pk_live_REPLACE_ME placeholder.
Sign in (free) to inline your live key →
Two MCP tools. One database.
Your agent writes a row, then asks a question.
Over MCP your agent calls
nlqdb_remember to write
a typed row, then
nlqdb_recall to ask in
English. nlqdb compiles the question to SQL through a typed-plan
trust boundary and runs it on Postgres.
2 · Recall
nlqdb_recall({
question: "feedback per user, ranked by count this month"
})Compiled SQL (the exact statement nlqdb ran):
SELECT user_id, COUNT(*) AS feedback
FROM agent_memory
WHERE category = 'user_preference'
AND created_at >= date_trunc('month', now())
GROUP BY user_id
ORDER BY feedback DESC;3 · The answer — one GROUP BY
| user_id | feedback |
|---|---|
| u_412 | 14 |
| u_207 | 9 |
| u_388 | 6 |
| u_104 | 4 |
| u_551 | 2 |
Rendered from a fixture through the same typed-plan compile path the product runs — server-rendered so it stays crawlable and works with no JS. Numbers are illustrative.
Recall is table stakes. Only one of these can aggregate.
| Capability | Mem0 | Zep | Letta | nlqdb |
|---|---|---|---|---|
| Remember a fact ("Alice has a $50k deal") Storing a fact is table stakes — every memory layer does this. | ||||
| Recall facts by similarity / relevance Retrieval is the job these tools are built for; nlqdb recalls via SQL filters. | ||||
| Top-N by value ("top 5 deals by size") Needs ORDER BY + LIMIT over the full set, not a top-k similarity search. | ||||
| Aggregate per group ("average deal size per stage") A vector/graph store returns matches; the LLM would have to do the arithmetic. nlqdb runs GROUP BY in Postgres. | ||||
| Time-window analytics ("deals closing this month") Zep tracks temporal validity for point-in-time recall, but cannot aggregate across a window. | ||||
| Full GROUP BY / JOIN / HAVING over memory The core wedge: a real query planner over the agent's own data. | ||||
| Agent designs its own schema nlqdb provisions Postgres from the agent's first goal; the others impose a fixed memory shape. | ||||
| Diff preview before destructive writes DDL/DML is previewed and confirmed before it applies (GLOBAL trust-UX). | ||||
| Self-hostable Mem0/Letta/LangMem are OSI-licensed; Zep self-hosts the Graphiti engine but the platform is hosted; nlqdb is source-available under FSL (GLOBAL-019, not yet OSI), with the container pull-forward tracked in WS-11. |
Five boxes — or one MCP tool.
- Vector store top-k
- Per-agent SQLite
- Embedding cache
- Schema design
- Re-rank pipeline
nlqdb_recall(…)
Connect over MCP.
nlqdb is a hosted MCP server. Add it to Claude, Cursor, Codex, or any MCP host — OAuth opens in your browser on the first tool call, no key wired up front.
1 · Paste the connector URL
Into your host’s MCP config — Claude Desktop, Cursor, Codex, Zed, Windsurf.
{
"mcpServers": {
"nlqdb": { "url": "https://mcp.nlqdb.com/mcp" }
}
}Or: one command
The nlq CLI auto-detects every installed host, signs
you in once, and patches each config in place.
nlq mcp installQuestions agent builders ask
- What is analytical memory for an AI agent?
- A real, queryable database an agent uses to remember — typed rows it can GROUP BY, JOIN, and aggregate over in plain English, not an opaque vector blob it can only search. Recall is table stakes; analysis over memory is the part a vector store structurally can't do.
- How is this different from a vector store or vector database for agent memory?
- A vector store returns the top-k most similar chunks — semantic recall with no query planner, so rollups become the model doing arithmetic over search hits. nlqdb stores typed rows in Postgres, so it answers “how many times did this user ask about pricing this month?” with one GROUP BY.
- Does my agent have to design a database schema first?
- No. The database is created from a goal, not a schema. Your agent writes typed rows as it learns and asks questions in English; nlqdb provisions the Postgres database and infers the shape.
- Is it safe to let an AI agent write SQL against its memory?
- The LLM never emits SQL. It returns a typed JSON plan; nlqdb's compiler emits parameterised SQL, an AST re-parse checks it against a verb and table allow-list, and destructive writes show a diff you confirm first — and every query returns the exact SQL it ran.
- Can my agent run similarity or vector recall too?
- Similarity search over an embedding column (pgvector) is an opt-in slice still landing. Today the wedge is the analytical side — the GROUP BY, JOIN, and per-group aggregate queries a vector store can't run.
- What does it cost, and can I use my own LLM key?
- Bring your own Anthropic, OpenAI, Gemini, or OpenRouter key at 0% markup on the free tier — no card, no per-call fees. The engine, CLI, MCP server, and SDKs are source-available under FSL-1.1 and self-hostable for any non-competing use.
See the side-by-side comparisons or the manifesto.