In Vanna AI
You already have a production database with curated schema documentation.
Open-source text-to-SQL trained on your schema and prior queries.
Comparison
nlqdb vs Vanna AI
Pick Vanna if you have an existing database and want an OSS layer that translates English into SQL against it. Pick nlqdb if you also want the database itself — provisioned, schema-managed, and queryable via SDK / CLI / MCP from day one.
The same goal, two ways.
> monthly revenue trend for the last 12 months
In your HTML
<nlq-data goal="monthly revenue trend for the last 12 months"></nlq-data>A reporting question Vanna would translate; nlqdb both translates it and owns the data it answers from.
What's different
Four dimensions that decide it
| Dimension | nlqdb | Vanna AI | Note |
|---|---|---|---|
| Owns the database (provisions + migrates) | |||
| Natural-language → SQL | |||
| Auto-migration via NL ('add a column for tags') | |||
| Trained on your prior queries (RAG over query history) | nlqdb caches plans per (goal-fingerprint, schema-hash); Vanna's training loop is more explicit. |
Show 6 more rows
| Dimension | nlqdb | Vanna AI | Note |
|---|---|---|---|
| HTML embed element | |||
| MCP server | |||
| Destructive-op diff preview | |||
| Multi-engine (Postgres + ClickHouse + …) | Vanna routes across many SQL dialects; nlqdb Phase 1 is Postgres, ClickHouse Phase 2. | ||
| Open source | |||
| Self-hostable |
shipped · partial · not shipped
When to choose nlqdb
- You don't have a database yet, or you want a fresh one for a new feature.
- You want the same engine to power a web embed, a CLI, and an MCP server.
- Destructive-op diff preview matters more than SQL training-data fidelity.
- You want anonymous-mode visitors to try queries before signing in.
When to choose Vanna AI
- You already have a production database with curated schema documentation.
- You want full control over the LLM stack and prompt engineering.
- OSS license matters for compliance or self-hosting.
- You need the translator-only shape and don't want a hosted product.
Questions buyers ask
- Can I point Vanna AI at an nlqdb database?
- Not directly. nlqdb's API speaks `/v1/ask` (English) and `/v1/run` (raw SQL with allow-list); Vanna expects a Postgres connection string. The right shape today is to use nlqdb for new data features and Vanna over a legacy DB you can't migrate.
- Is nlqdb's NL→SQL quality competitive with Vanna's?
- Both fine-tune the prompt against the live schema. nlqdb publishes BIRD Mini-Dev + Spider 2.0-lite scores to `docs/features/quality-eval/`; Vanna doesn't publish a single canonical benchmark, so the honest answer is 'measure yours on your schema.'
- Do I need to write training examples like in Vanna?
- No — nlqdb prompts directly from the schema fingerprint + recent-tables hint. Training examples are a Vanna-specific lift; nlqdb's equivalent is the per-tenant plan cache, which is automatic.
- Which one is better for an AI agent over MCP?
- nlqdb ships an MCP server with `nlqdb_query`, `nlqdb_list_databases`, and `nlqdb_describe` — `nlqdb_query` materialises Postgres on first reference, so the agent never calls a separate create-DB verb. Vanna doesn't ship an MCP server today, so an agent has to wrap the Python SDK itself.
- Can I migrate from Vanna to nlqdb without rewriting my queries?
- Your end-user query strings (English goals) port directly. The schema needs to be re-created in nlqdb (or imported from a SQL dump) because nlqdb owns the database. The integration code shrinks — one `<nlq-data>` tag or one SDK call replaces a translator-plus-DB-client pair.
Try nlqdb in 30 seconds
No sign-in. The anonymous database lasts 72 hours; adopt it with one click if you keep it.
Start with a goal →