nlqdb — analytical memory for AI agents

Memory your agent can query, not just recall — a real database it reaches over MCP.

Connect nlqdb to Claude, Cursor, Codex, or any MCP host. Your agent writes typed rows as it learns, then asks questions in plain English — GROUP BY, JOIN, aggregate over what it remembered. A vector store returns the top-k similar chunks; nlqdb runs the query a similarity index structurally can't. The LLM never emits SQL: it returns a typed plan, our compiler emits the parameterised statement, and you see the exact SQL every time.

It's also a natural-language database for any app. You write HTML; each component asks for what it wants in plain English; nlqdb infers the schema, writes the SQL, runs it, and renders the result. There is no backend for you to build.

Two actions. That's the whole product:

1. Create a database — one word: a name (or a goal).
2. Talk to it in plain English.

<script src="https://elements.nlqdb.com/v1.js" type="module"></script>

<nlq-data
  goal="the 5 newest orders, with customer and item"
  api-key="pk_live_xxx"
  template="table"
  refresh="10s"
></nlq-data>

That's the entire backend for a live order list — no API to write, no schema to define, no JSON to parse. Engine choice (Postgres / Mongo / Redis / DuckDB / pgvector / …), schema inference, indexing, backups, and auto-migration between engines based on your real workload are background concerns you never have to see.

Status — early, open

nlqdb is early and built in the open, but fully public — no gate, no invite code. The marketing site, the /v1/ask pipeline, the <nlq-data> / <nlq-action> elements, the chat app, the TypeScript SDK, the hosted MCP server, and the nlq CLI are all live in some form (see the surface table below). Natural-language → SQL accuracy is still climbing toward our public bar (BIRD ≥ 0.65, Spider 2.0 ≥ 0.75 on the free model chain), so answers can be wrong — every response carries a confidence signal and the SQL it ran.

Known gap — npm i @nlqdb/sdk is not usable yet. Every version published so far (through 0.2.1) declares its entrypoints as ./src/index.ts while shipping only dist/, so importing it fails with ERR_MODULE_NOT_FOUND. Measured against the live registry, not inferred. The manifest is fixed in this repo and a CI guard now pins every publishable package's entrypoints inside its own files allowlist, but the registry stays broken until 0.2.2 publishes. Until then, use the <nlq-data> element, the HTTP API, the CLI, or npx -y @nlqdb/mcp (0.1.0, verified installable from a clean registry). Building from a clone is unaffected.

Use it

Connecting an agent over MCP? One command, plus one browser-OAuth approval: Give your agent memory. Headless hosts skip the browser with npx -y @nlqdb/mcp and an sk_live_* key (MCP setup).

The 60-second walkthrough — plain HTML, CLI, and ten framework wrappers — lives at docs.nlqdb.com. Start with the HTML tutorial or the CLI tutorial.

You don't generate an API key separately: describe your database at nlqdb.com, and the chat hands you a <nlq-data> snippet with the key already inlined.

Examples

examples/ — minimal scaffolds in plain HTML, Next.js, Nuxt, SvelteKit, Astro, plus a CLI-only walkthrough. Each is the smallest valid integration around one <nlq-data> element or one CLI session.

What makes it different

Four things every release has to move, none allowed to regress (GLOBAL-025):

• Engine quality — natural-language → SQL accuracy (measured continuously on BIRD + Spider 2.0 + an internal eval), plus the multi-engine layer that moves your data to the right engine f

... View full README on GitHub