The platform
Every feature serves one rule: never invent.
An answer must come from rows your database actually returned. Everything below — the guard, the deny-lists, the audit log — exists to enforce that.
Answers from real rows
The model answers exclusively from the rows the guarded query returned. No outside knowledge, no invented fields, prices, counts or dates. When the query returns nothing it says so instead of guessing — a wrong answer is treated as a bug, not a quirk.
One guarded SELECT
SqlGuard allows exactly one read-only SELECT per question — no DML or DDL, no stacked statements, no comments, never SELECT *, always an enforced LIMIT. Anything else is rejected before it gets near your database.
JOINs along real foreign keys
The model is given your actual foreign keys and indexed columns, auto-discovered from the schema, and instructed to join and filter along them only. Cross-table questions work the way your schema intends — and stay fast.
Read-only, with a stopwatch
Every generated query runs through a read-only connection under a database-side statement timeout, so a heavy query is killed by the server, never by luck. Failures feed a bounded repair loop. Point it at a SELECT-only DB user for defence in depth.
Column deny-list, three ways
password, token, secret, api_key, remember_token and anything matching your own patterns are stripped from the schema the model sees, rejected by SqlGuard if a query names them, and removed from result rows before they reach the model.
Clarifying questions
When a question is genuinely ambiguous, the model asks up to three short questions instead of guessing, then answers with your replies in context. Turn it off with --no-clarify to always get a best-assumption answer.
Auditable, query by query
Every question, answer and request id lands in your dashboard conversation log, and --show-sql prints the exact SELECT that ran. Any answer can be traced back to the query and the rows it came from.
Self-host or hosted
Point the package at your own Ollama with a SQL-capable model for a fully self-hosted stack, or let DBMind Cloud write the SQL with frontier models via OpenRouter while it validates keys, subscriptions and quotas. Guarding and execution stay on your server either way.
Field-level encryption in cloud mode
Before result rows leave your server for phrasing, private text values — names, emails, phone numbers, addresses — are sealed into AES-256-GCM tokens. The cloud model copies them blindly, your package decrypts the answer locally, and the encryption key never leaves your server. Numbers stay readable so rankings and totals still work.