Solve
Specific problems, with a working snippet
One page per recurring search query — each answers the question with a working
<nlq-data> embed and names what nlqdb doesn't do for
that shape. Pages that hide their limits don't earn citations, and they don't
earn trust.
Solo builders
Founders and single engineers shipping side-projects on weekends. Spend day one of every project wiring up Postgres, ORMs, and migrations before the app does anything useful — they'd rather skip that step and ship.
-
How do I add a database to a side project without setting up Postgres?
If your side project needs a database but you don't want to provision Postgres, choose an engine, or wire migrations, drop one `<nlq-data>` tag in any HTML page — nlqdb mints the database, infers the schema from your first English query, and exposes the same data via SDK / CLI / MCP.
-
How do I add a leaderboard to a small product without writing SQL?
If your product needs a leaderboard, a top-N table, or a ranked list and you don't want to author SQL or wire a ranking ORM call, write the goal in English in one `<nlq-data goal="top players by score">` tag — the database, the schema, and the index decisions are all behind the element.
-
How do I store and query form submissions without a backend?
If your landing page needs to capture form submissions — a waitlist, contact form, or survey — without running a backend, give nlqdb a database: write each submission with the SDK or a `POST /v1/run` insert, then ask 'signups per day' or 'replies by source' in plain English.
-
How do I track product usage events and query them without a data warehouse?
If you want to track product usage — signups, feature clicks, retention — and ask 'active users this week' without standing up Snowflake or paying Mixpanel per event, give nlqdb a database: emit each event with the SDK or a `POST /v1/run` insert, then ask the rollup in plain English with the SQL shown.
Agent builders
Engineers building LLM-powered agents that need to remember things across sessions. Structured memory has had no opinionated primitive — most teams stitch together a connection string, an ORM, and a hand-rolled migration loop before the agent's first tool call.
-
How do I give Claude or Cursor a SQL database it can create and query?
If you want Claude Desktop, Cursor, or any MCP host to have a SQL database — not just a connection to one you configured yourself — point it at nlqdb's hosted MCP server. The `nlqdb_query` tool provisions Postgres from the agent's first English goal (no connection string, no schema) and answers in English with the SQL shown.
-
How do I give my AI agent persistent memory across sessions?
If your agent needs to remember facts across sessions and later *aggregate* them, give it a real database via MCP — nlqdb's `nlqdb_query` tool provisions Postgres from the agent's first English goal and answers `GROUP BY` / top-N / per-period questions over what it stored. Retrieval gets you one fact; analytics gets you the report.
-
How do I run reports over what my AI agent remembered?
If your agent stores what it learns and you now need *reports* over that memory — counts, top-N, averages per group — point an MCP-aware agent at nlqdb and ask in English. It runs the `GROUP BY` in Postgres and returns rows plus the SQL. A vector store recalls one fact; a database answers 'top 10 this month.'
-
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.
-
How do I track and query my AI app's token usage and cost per user?
If your LLM app needs to track token usage and cost — per user, per model, per day — log each call as a row and ask in English. nlqdb provisions Postgres from your first goal and runs the GROUP BY in SQL, so 'spend per user this month' is a real query, not arithmetic over a JSON log.
-
How do I log my AI agent's tool calls and query which tool fails most?
If your agent calls tools and you need to know which tool fails most and how slow each one is — log every tool call as a row and ask in English. nlqdb provisions Postgres from your first goal and runs the GROUP BY in SQL, so 'error rate per tool' is a real query, not a grep over traces.
-
How do I log my RAG retrievals and query which sources get used most?
If your RAG agent retrieves chunks and you need to know which sources get used most — log each retrieval as a row and ask in English. nlqdb provisions Postgres from your first goal and runs the GROUP BY in SQL, so 'retrievals per source this week' is a real query, not a scan over a vector-store log.
-
How do I track and query my LLM eval scores across prompt versions?
If you run LLM evals and need to know which prompt version regressed — log each scored case as a row and ask in English. nlqdb provisions Postgres from your first goal and runs the GROUP BY in SQL, so 'pass rate per prompt version this month' is a real query, not a spreadsheet pivot.
-
How do I safely give an AI agent database access without it running dangerous SQL?
If you want an AI agent to use a database without handing it a connection string and hoping it never emits a DROP, nlqdb keeps the agent on the data side of a trust boundary: writes are server-built parameterised inserts, read SQL passes a fail-closed three-stage validator, Postgres RLS isolates every row, and the compiled SQL is always shown.
-
How do I give multiple AI agents shared, persistent memory?
If you want a crew of agents to share one memory instead of each keeping its own, nlqdb gives them a single Postgres they all write to with `nlqdb_remember` and recall in English — every row tagged with the agent that wrote it, so you can roll the team's memory up per agent.
-
How do I isolate AI agent memory per tenant so accounts can't read each other?
If your agent stores memory for many customers and one tenant's rows must stay invisible to another, nlqdb enforces it in the database: every provisioned Postgres carries a row-level-security policy keyed on the tenant, set per request, and fails closed — a missing scope returns no rows, never someone else's.
-
Should I build my own agent memory on Postgres or buy it?
If you already run Postgres and are deciding whether to hand-roll agent memory, a `memories` table is easy to start and expensive to get right at scale. nlqdb is the buy answer: one MCP command gives your agent a real database it writes rows to and queries in English, with tenant isolation enforced in the engine.
-
What's the best way to store what my AI agent remembers?
If you're choosing how to store what your AI agent remembers, the storage shape decides what you can ask later — a vector store recalls one fact but can't count them. Store memory as typed rows in a real database: one command (`claude mcp add --transport http nlqdb https://mcp.nlqdb.com/mcp`) gives your agent one it writes to and queries in English.
-
How do I expire old agent memory automatically instead of writing a cron?
If stale agent memory is piling up, give it an `expires_at` timestamp on typed rows in a real database — then expiry is a one-line `WHERE expires_at < now()` predicate you query in English, not a bespoke cron. One command (`claude mcp add --transport http nlqdb https://mcp.nlqdb.com/mcp`) gives your agent that database.
-
Is there an MCP server that gives my AI agent memory?
If you want an MCP server that gives your AI agent memory, point your coding agent at nlqdb's hosted one with one command — `claude mcp add --transport http nlqdb https://mcp.nlqdb.com/mcp`. Unlike a blob-store memory server, it's a real Postgres your agent writes to and queries in English, so 'how many' and 'top N' are SQL, not guesses.
Analysts and PMs
PMs, ops, and customer-success leads who can write SQL but resent it. Live in Metabase, Retool, and Excel — want one-off questions answered without filing a data ticket, and want internal dashboards that don't charge per viewer.
-
How do I build an internal dashboard without per-seat pricing?
If you need an internal view over your data and per-seat tooling is out of budget, drop an `<nlq-data>` tag in any HTML page and ask for the report in English — no SQL, no schema setup, no per-viewer fee.
-
How do I run natural-language queries on a database without training a model on my schema?
If you want English → SQL on your data but don't want to maintain a training corpus or RAG layer, point `<nlq-data>` at your goal — nlqdb prompts directly from the live schema fingerprint, caches the plan, and shows the compiled SQL so you can verify before trusting it.
-
How do I answer ad-hoc data questions without waiting on the data team?
If a simple number means filing a data ticket and waiting days, ask the question in English instead — drop an `<nlq-data>` tag in any page or open the chat, and nlqdb compiles the SQL, runs it, and returns the rows plus the query to audit. No ticket, no analyst in the loop.
-
How do I find duplicate rows in my data without writing SQL?
If you need to find duplicate rows — the same email twice, an import that ran twice, a customer entered three times — ask in plain English instead of hand-writing GROUP BY ... HAVING. nlqdb compiles the dedup query, runs it in Postgres, and shows the SQL, so you see exactly which rows repeat and how many times.
-
How do I get the top N rows per category without window-function SQL?
If you need the top N rows in each group — the 3 best-selling products per category, or the latest order per customer — ask in plain English instead of hand-writing a window function. nlqdb compiles the ranked query, runs it in Postgres, and shows the SQL so you trust the partition and tiebreak.
-
How do I pivot rows into columns in SQL without writing a crosstab query?
If you need a pivot table — rows turned into columns, like revenue per product with one column per month — ask in plain English instead of hand-writing a crosstab. nlqdb compiles the conditional aggregation, runs it in Postgres, and shows the SQL so you can verify the buckets.
-
How do I calculate a running total or cumulative sum in SQL?
If you need a running total — a cumulative sum that grows row by row, like revenue-to-date by day — ask in plain English instead of hand-writing a window function. nlqdb compiles the `SUM(...) OVER (ORDER BY ...)`, runs it in Postgres, and shows the SQL so you can verify the ordering and frame.
-
How do I calculate month-over-month growth or period-over-period change in SQL?
If you need month-over-month growth — this period's value versus the previous one, as a percentage — ask in plain English instead of hand-writing a LAG window function. nlqdb compiles the `LAG(...) OVER (ORDER BY ...)` and the growth formula, runs it in Postgres, and shows the SQL so you can verify the order and the divide-by-zero guard.
-
How do I calculate a median or percentile in SQL?
If you need a median or a percentile — the middle value, or the p90 of response times — ask in plain English instead of remembering Postgres has no `MEDIAN` function. nlqdb compiles the ordered-set aggregate `PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY value)`, runs it in Postgres, and shows the SQL so you can check the order.
-
How do I calculate each row's percentage of the total in SQL?
If you want each row as a share of the whole — a product's revenue as a percent of all revenue — ask in plain English instead of self-joining to a total. nlqdb compiles the window aggregate `100.0 * revenue / SUM(revenue) OVER ()`, runs it in Postgres, and shows the SQL so you can check the denominator.
-
How do I find rows in one table with no match in another (anti-join) in SQL?
If you need the rows in one table with no match in another — customers who never placed an order — ask in plain English instead of hand-writing an anti-join. nlqdb compiles the `LEFT JOIN ... WHERE b.id IS NULL` (or `NOT EXISTS`), runs it in Postgres, and shows the SQL so you can dodge the `NOT IN` NULL trap.
-
How do I count rows per day in SQL, including days with zero rows?
If your per-day counts skip the days with no rows — a signup chart with holes where the zeros should be — ask in plain English. nlqdb compiles the `generate_series` calendar spine, LEFT JOINs your rows onto it, runs it in Postgres, and shows the SQL, so quiet days come back as 0 instead of vanishing.
-
How do I group numbers into ranges (buckets) in SQL?
If you want a count per range — orders under $50, $50–$200, over $200 — instead of one row per exact value, ask in plain English. nlqdb compiles the bucket expression, GROUP BYs the bucket, orders the ranges by their lower bound, and shows the SQL, so 5–10 sorts before 10–20 instead of after.
-
How do I count a streak of consecutive days in SQL?
If you want each user's longest run of consecutive active days — not just their total active days — ask in plain English. nlqdb compiles the gaps-and-islands query (the date-minus-row-number trick that turns each unbroken run into one group), counts the days per run, and shows the SQL.
Backend engineers
Engineers at small startups running their own Postgres. Want a natural-language admin layer over the database they already own — not a replacement for the data store underneath.
-
How do I add a natural-language query layer over my existing Postgres?
If you already run Postgres and want to ask it questions in English — without building or training a text-to-SQL stack — connect it to nlqdb with `nlq db connect` (or `POST /v1/db/connect`). nlqdb introspects your live schema, compiles English to SQL, runs it on your own database, and shows the SQL every time. Your data never leaves your Postgres.
-
How do I add an ask-your-data feature to my app without building text-to-SQL?
If you want to ship an 'ask your data' feature in your app but don't want to build and maintain a text-to-SQL pipeline, embed nlqdb: drop the `<nlq-data>` element (or call `POST /v1/ask` from your backend), and it compiles English to SQL, runs it, and returns rows plus the SQL — buy the pipeline, don't build it.
-
How do I store webhook events in a database I can query in plain English?
If you receive webhooks from Stripe, GitHub, or Twilio and want to ask 'how many events per type this week' without standing up a database first, write each verified payload to an nlqdb-provisioned Postgres and ask the report in English — the compiled SQL is shown underneath.
-
How do I log my background jobs and query which one fails most?
If your cron and background jobs fail silently and you need to know which one fails most — log every run as a row and ask in English. nlqdb provisions Postgres from your first goal and runs the GROUP BY in SQL, so 'failure rate per job this week' is a real query, not a grep over scheduler logs.
Have a problem we don't cover?
Email the search query you typed; if it matches a recurring theme in our ICP-mining cluster file, the page ships the same week. See also competitor comparisons.