nlqdb

Manifesto

A database you talk to,
with a backend that doesn’t exist.

nlqdb is a natural-language database: you create one with a name, you query it in English, and the schema, the engine, the indexes, the migrations and the cache are all background concerns you never have to see.

What follows is the bar every change is judged against. If a change violates one of these, it doesn’t ship. Not as guidelines — as acceptance criteria.

What is nlqdb? A database that accepts natural language as its query language, picks the right engine for your workload (Postgres, ClickHouse, Redis, …), and exposes itself through five surfaces — an HTML element, a typed SDK, a CLI, an MCP server, and a chat web app — all backed by the same engine. The free tier is the same engine paying customers run on; the escape hatch to raw SQL stays one click away, always.

  1. 01

    Free. Forever.

    You can sign up, build a thing, and ship it to production without a credit card. That isn't a trial. That's the product.

    Every cost upgrade is gated on a real signal — usually that someone is paying us for the thing they shipped. Until then the bill is zero, the limits are honest, and the free tier is the same engine paying customers run on.

  2. 02

    Open source. By default.

    The engine, the CLI, the MCP server, the SDK — all under FSL-1.1-ALv2. Source-available now, Apache 2.0 in two years. The cloud is a convenience, not a moat. If we ever try to wall something off, you can fork the engine and run it yourself.

  3. 03

    Simple. One way to do each thing.

    Two endpoints. Two CLI verbs. One chat box. No config files in the first 60 seconds. No “pick a region.” No schema. fetch is the SDK.

    Every error is one sentence with the next action. If a feature needs a tutorial to use, it failed. If two engineers disagree on a design, we ship the simpler one.

  4. 04

    Effortless UX.

    Zero modals. Zero “are you sure?” except for destructive actions. Keyboard-first. The chat is the product; everything else is a disclosure that you opt into when you actually need it.

  5. 05

    Seamless auth — one identity, four surfaces, zero friction.

    No login wall before first value. Every surface produces a working answer before asking who you are. The DB you create before signing in adopts to your account when you do.

    One sign-in covers everything. Web, CLI, every MCP host — same identity. Tokens refresh silently. You will never see a 401.

    Credentials live in the OS keychain. Revocation is instant and visible. Every token on every device, listed with last-used; one click revokes it.

  6. 06

    Goal-first, not DB-first.

    Nobody woke up wanting to create a database. They woke up wanting a meal-planner, an agent that remembers them, the number for the 4pm sync. The database is plumbing.

    Every surface starts with a goal. The DB materialises as a side effect, named after the thing you described, ready to query. You can always reach the raw Postgres URL — it’s one click away — but you almost never need to.

  7. 07

    Bullet-proof by design — not by handling.

    We make bad states unreachable, not branched on. Schemas only widen, so there is no “schema mismatch” code path. Every mutating call carries an idempotency key, so retries are safe by construction. Plans are content-addressed, so cache invalidation has nothing to invalidate.

    Destructive operations require a diff preview and a second confirm. Numeric inputs are bounded, so there is no NaN, no overflow. Secrets are scoped per-DB, so there is no “wrong tenant” branch to write a test for.

  8. 08

    Creative. By policy.

    The product looks and feels nothing like a Tailwind template. Personality is required. Acid lime on near-black, JetBrains Mono headlines, hard shadows, kinetic typography on the words that matter. Stock photos are forbidden. Logo grids are forbidden. “Trusted by” is forbidden.

  9. 09

    Fast. Measured.

    p50 query under 400ms on cache hit. p95 under 1.5s on cache miss. Cold start under 800ms. CLI binary under 8MB, starts in under 30ms.

    Marketing site: Lighthouse 100 on every metric. First paint under 600ms on 4G. Numbers exist so we can fail them in CI, not so we can quote them in a deck.

The on-ramp inversion.

The single most important design decision: every entry point accepts a goal, not a database name. Every surface, reframed.

Surface-by-surface inversion of the first action.
Surface Old — DB-first New — goal-first
Marketing hero “Name your database” “What are you building?”
Platform first run “Create database” button One chat input; DB created silently
CLI first command nlq db create orders nlq new "an orders tracker"
MCP first call nlqdb_create_database("memory") nlqdb_query("memory", "remember…")
HTML element db="orders" required goal="…" leads; db inferred

What this isn’t.

  • Not a SQL builder. There is no “here is your generated SQL, paste it into your ORM” step.
  • Not a vector store with a wrapper. Postgres with pgvector is one of the engines under the hood, not the product.
  • Not a chat-on-top-of-your-warehouse layer. We own the storage too. Otherwise schema, indexes and migrations leak back into the user’s brain.
  • Not a no-code tool. The whole point is that developers stay in their editor, in their language, against their build. nlqdb is a backend, not a GUI.

← Back to the snippet