A lot of the data worth asking questions about is the exact data you are not allowed to paste into a cloud chatbot. Customer records, account balances, patient files, contracts, case history: your sensitive data. The moment it leaves your machine, it becomes someone else’s log to keep.

To show what local AI makes possible, we built a demo: an illustrative example, not a QVAC product, that turns a plain-English question into SQL and runs it against your database, with the AI model running entirely on your own machine. It is built on the QVAC SDK, and the point is the pattern, so you can clone it and make it your own. See it in action here.

A local AI that turns plain English into SQL, on hardware you control

You type “top 3 clients in Frankfurt with the biggest debt”, a local model writes the SELECT, and the query runs on-device. No cloud model, no API key, no per-token bill, and the one thing a cloud tool can never promise: your data never leaves the machine.

The cloud-AI gap, and where local fits

Cloud AI is excellent until the data is sensitive. Then the useful thing and the safe thing pull apart: a natural-language-to-SQL helper would save your analysts real time, but only if the question, the schema, and the results never leave your control. The usual answers (redact the data, sign a data-processing agreement, route through a vetted endpoint) all add cost and review, and none of them remove the core fact that the data went out.

Running the model on-device changes the property, not just the policy. There is no outbound request to review, no prompt log on a server you cannot see, no token bill. That is not specific to banks. It is the same shape in healthcare, legal, public sector, or any team whose data sits under a confidentiality rule. This build example uses a fictional bank only because it is an easy story to follow; the pattern is the point, not the dataset.

What the demo does

The demo is a native desktop window where you:

• Type a question in plain English. A local model reads only your database schema, never the row data, and writes a single SELECT.
• Watch the query run against an in-memory SQLite database and see the rows in a results table. The numbers are computed locally, not guessed by the model.
• Explore a fictional demo bank (customers, accounts, transactions, loans, an audit log) so you can try it with zero setup.
• Flip a technical toggle: off, you get a plain-English summary of what the query does; on, you see and can edit the SQL before it runs.
• Stay read-only by design: anything that would change data is blocked before it reaches the database.

Two design choices are what make it safe to point at real data: only the schema and the question ever reach the model (never the rows), and a read-only guard refuses anything that is not a read, so a wrong or adversarial query cannot change or delete anything.

Why local

• Your machine, your model. On-device inference with a local Qwen3 4B model. No cloud LLM, no API key for the AI.
• Your data stays put. The question, the schema, and the results never leave the device. Nothing to review, nothing to log elsewhere.
• Free to run. No per-token or per-use cost. The first run downloads the model once (about 3 GB) and caches it.

Recommended hardware

Local AI runs on your own machine, so the experience is hardware-bound. The demo keeps one model resident (Qwen3 4B, 4-bit, 16k context):

• GPU: any discrete GPU via Vulkan (NVIDIA, AMD, Intel) on Linux and Windows, or Apple Silicon via Metal on macOS. CPU-only works but is slow.
• RAM: 16 GB is comfortable for the 4B. On 8 GB, drop to the 1.7B model.
• Disk: about 3 GB for the model, downloaded once and cached.
• Node.js 22.17 or newer.

Make it yours

This ships as an example, not a product. It is a starting point you are meant to take apart:

• Point it at a real read-only SQLite file instead of the demo data set.
• Swap the demo schema for your own and keep the read-only guard.
• Add CSV or JSON export of the results table, all local.
• Stream the model’s reasoning live as it writes the query.
• Constrain the model’s output to a fixed schema so the result is always valid structured data.

Want your AI coding agent to make the change for you? Point it at the repo and hand it this prompt:

You are updating a local-AI natural-language-to-SQL example built on the QVAC SDK. Read the repo at https://github.com/tetherto/qvac-examples, and fetch https://docs.qvac.tether.io/llms-full.txt
as your source of truth for anything SDK-related (grep it before writing any QVAC code, and never invent APIs). Then make this change: [describe what you want]. Keep all model inference 100% on-device, keep only the schema and the question reaching the model (never row data), and run the app to confirm it works before you finish.

Get it

Clone the example and run it:

git clone https://github.com/tetherto/qvac-examples
cd qvac-examples/qvac-natural-language-to-sql
npm install
npm start

Or start your own local-AI project from scratch with the SDK:

npm install @qvac/sdk

Everything runs on your machine. QVAC SDK is open source (Apache 2.0) and free. Docs: docs.qvac.tether.io. If you build something with it, star the repo and show us.

A note on what this is

This is not a new QVAC product. It is an illustrative example, built to show what a local AI agent can do with the QVAC SDK: real structured data, on-device inference, and nothing leaving the machine, in one small app. The bank is fictional and there are no real people in it.

The QVAC example program described in this post is an illustrative example only and provided “as is.” You are responsible for what you build whether you use this example or not, including ensuring it complies with applicable laws and is appropriately safeguarded. Use of the QVAC example program described in this post is subject to the Tether.io Website Terms.

Link to the GitHub repository: https://github.com/tetherto/qvac-examples/tree/main/qvac-natural-language-to-sql