AI · private by design

An AI assistant that writes SQL — without shipping your data off

Ask in plain English; bzora drafts the SQL into your editor, explains your schema, and helps you drive the app. By default it runs on a local model you control — no account, no API key, nothing leaves your machine. Prefer a cloud model? Bring your own key. Either way, the part that decides what's even worth answering always runs locally.

Why it's different from the AI in other clients

Most database clients that added AI pipe your schema — sometimes your data — to a cloud model you don't control. bzora's assistant is built the other way round: local by default, yours to audit, and unable to touch your data on its own.

What you get	How
Private by default	Runs on a local model out of the box — your question, schema and answer never leave your machine. Even with a cloud key, the scope gate and table-selection still run locally; only the in-scope question and the few relevant tables are sent.
No lock-in, no markup	Bring your own key across three backends — a local runtime (Ollama / llama.cpp), any OpenAI-compatible endpoint, or Anthropic. You pay your provider directly; bzora never proxies your traffic or marks up a token.
You can audit every turn	Each question shows a trace — the provider, model, exact egress host, and the exact prompt that left your machine, or that nothing did. No guessing about what got sent.
Safe by construction	Generated SQL never runs on its own. It lands as a card you insert yourself, badged so a statement that changes data is obvious before you ever run it.
Focused, not a chatbot	A scope rule keeps it a database assistant, not a general chatbot — off-topic questions get declined, not answered. Add the optional local embeddings gate and they're refused before the model runs at all, for free.
Scales to big schemas	Small schemas go to the model whole; larger ones are narrowed — on your machine — to just the tables your question needs, so the model never sees your entire database.

What it does

Writes SQL from a question — "last month's orders by country" becomes a query, dropped into a real editor tab.
Explains the database — a table, a relationship, or a query you're staring at.
Teaches the app — how to filter, join, or run something in bzora.
Refuses the rest — it's a database assistant, not a general chatbot, and it says so politely.

Generated SQL never runs on its own. It lands in the editor; you read it and press run. A statement that changes data asks for a second confirmation first, and a hallucinated column simply errors when you run it — it can't quietly touch your data.

How it works

Every question goes through three steps — and the first two always run on your machine:

Step	Runs	What happens
1 · Gate	Local	Applies the scope rule — is this about SQL, this database, or the app? By default the generator declines anything off-topic; add the optional embeddings gate and off-topic questions are refused locally, before the model is ever called.
2 · Retrieve	Local	Picks the handful of tables relevant to your question out of your whole schema, so the model gets focused context instead of all 200 tables.
3 · Generate	Local model or your cloud key	Writes the SQL or the explanation, streamed back as you watch.

Only step 3 can reach the cloud, and only if you choose a cloud key. Steps 1 and 2 — the gate and the table-picking — never leave your machine, in any mode.

Optional: a sharper scope gate with local embeddings

Out of the box, bzora is embedding-free — the gate and table-picking run locally with no extra model to install (setup is below). If you want a stronger scope filter and semantic table-matching, you can point it at a small local embeddings model: one that turns text into numbers such that similar meanings land close together. "how many customers" and "count the users" come out near each other; "write me a poem" lands far away. It's a fast "meaning ruler" — text in, numbers out, no writing involved.

Switched on, bzora uses that ruler for two jobs the chat model shouldn't do:

Filtering (the gate). Every message is embedded and checked against what "on-topic" looks like. A fixed classifier on embeddings is cheap, instant, and can't be jailbroken — so an off-topic question is turned away before the model runs, for free, and with a cloud key its text never egresses.
Picking tables (retrieval). Embeddings rank your tables by meaning — and catch matches a keyword search would miss, like a question about "users" finding a tbBenutzer table.

You don't need it. Embedding-free mode does the same two jobs locally — a prompt-based gate and lexical (keyword) table-ranking — so nothing egresses either way. The one honest trade-off: without the embeddings gate, an off-topic question reaches the generator once (declined in the model's own words, and billed if you're on a cloud key) instead of being refused for free. Add the embeddings model if you hit a schema where keyword-ranking misses a table, or you want that free off-topic refusal.

Set it up

bzora ships as just the app — it doesn't bundle a multi-gigabyte model. You point it at a model runtime you run, configured under Settings → AI assistant. Out of the box it's embedding-free, so there's really only one decision: the generator — run it locally, or hand it to a cloud key. (An embeddings model is optional; see above.)

By default, nothing extra runs for the gate and table-picking. Embedding-free mode handles both locally — a prompt-based scope gate and lexical table-ranking — so there's no embeddings server to stand up. The only thing you configure is the generator. Point that at a cloud key and nothing runs locally at all — just paste the key.

Want the sharper scope gate and semantic table-matching described above? Switch off embedding-free mode under Settings → AI assistant and point bzora at a local embeddings model — the simplest is Ollama's nomic-embed-text (Option A); with raw llama.cpp it's the --embedding server:

llama-server -hf nomic-ai/nomic-embed-text-v1.5-GGUF \
  --embedding --pooling mean -b 2048 -ub 2048 \
  --host 127.0.0.1 --port 8081

Then pick how the generator runs:

Option A — Ollama (easiest)

Ollama runs quietly in the background and serves the chat model. Install it, then pull one:

ollama pull qwen2.5-coder:7b

In bzora, set Generator to Local and fill in:

Generator URL http://localhost:11434 · model qwen2.5-coder:7b

Click Test connection, then Save. That's it. Want the embeddings gate too? Also ollama pull nomic-embed-text, switch off embedding-free mode, and set Embeddings URL to http://localhost:11434 · model nomic-embed-text.

Option B — llama.cpp

Prefer raw llama-server? For the default embedding-free setup you run just one instance — the chat model. Use a small, non-reasoning coder model; a "thinking" model spends minutes reasoning before it answers, which you don't want for everyday SQL:

llama-server -hf bartowski/Qwen2.5-Coder-7B-Instruct-GGUF:Q4_K_M \
  --jinja -c 8192 -ngl 99 \
  --host 127.0.0.1 --port 8080

Point Generator URL at http://localhost:8080. Adding the embeddings gate? Run a second instance with the --embedding flag (and a roomy physical batch so wide tables fit), switch off embedding-free mode, and set Embeddings URL to its port:

llama-server -hf nomic-ai/nomic-embed-text-v1.5-GGUF \
  --embedding --pooling mean -b 2048 -ub 2048 \
  --host 127.0.0.1 --port 8081

Option C — your own cloud key (BYOK)

Don't want to run a chat model locally? Set Generator to OpenAI-compatible or Anthropic, choose a model, and paste your API key — it's stored in your OS keychain, never in a file or sent to bzora's servers. Because bzora is embedding-free by default, that's the whole setup: nothing runs locally at all, and your key pays only for the in-scope questions that reach step 3.

Want a sharper local scope gate on top? Switch off embedding-free mode and add a local embeddings model (Ollama's nomic-embed-text is the simplest) — the cloud key still covers only generation.

What stays private

Local model

Nothing leaves your machine — question, schema, and answer all stay local. No account, no key, no per-query cost. The privacy default.

Cloud key (BYOK)

Only in-scope questions plus the few relevant tables reach your chosen provider. The gate and retrieval still run locally; your key lives in the OS keychain. You control the model and the bill.

In both modes there's no bzora telemetry, and generated SQL never executes without your click. It's the same posture as the rest of the app — see how bzora handles credentials and the full privacy page.

An honest word on the setup

The assistant needs a generator somewhere — that's the cost of not sending your data to a vendor by default, and of keeping the app a small download instead of a bundled multi-gigabyte binary. A cloud key needs nothing local at all; the local path is about a five-minute, one-command Ollama setup. Small local models aren't GPT-class, but they're more than good enough for the everyday "draft me this query" loop — and when you want more, you point the same assistant at a bigger cloud model without changing anything else.

Download bzora free Buy — $39

New to bzora? Start with the native, no-Electron client, or see how it compares to the tools you already use.