← Blog · May 25, 2026 · 8 min read · by Robert Ishimwe

Natural-Language SQL with a Local LLM: Connect dbclaw to Ollama

Cloud AI tools want your schema, sometimes your data, and always your API budget. With a local model through Ollama, you can turn plain English into SQL with nothing leaving your computer — no API key, no per-token bill, and it works on a plane. Here's the full setup.

If you work with databases that hold customer data, health records, or anything under NDA, sending even your schema to a third-party API can be a non-starter. dbclaw is a local-first desktop app that turns questions into read-only SQL — and it can run that translation on a model hosted entirely on your own machine via Ollama.

Why run the model locally?

• Privacy: your question, schema, and results stay on your hardware. Nothing is sent to any company.
• Cost: no API key, no usage charges. Run as many queries as you like.
• Offline: once the model is pulled, you don't need an internet connection.
• Compliance: for regulated data, "the data never left the building" is a much easier conversation.

What you'll need

• A Windows 10/11 PC with a reasonable amount of RAM (8 GB works for small models; 16 GB+ is comfortable). A GPU helps but isn't required.
• Ollama installed.
• dbclaw installed (download here).
• A database to query — Postgres, MySQL, SQL Server, SQLite, MongoDB, or a spreadsheet.

Step 1 — Install Ollama and pull a model

Install Ollama from ollama.com, then pull a model from your terminal:

ollama pull llama3.1:8b

Make sure the Ollama server is running (it usually starts automatically; otherwise run ollama serve).

Which local models work?

dbclaw drives the model with tools — it asks the model to call functions to inspect the schema and propose SQL. That means you need a tool-capable model. These work well:

Step 2 — Install dbclaw

Download the *-setup.exe from the releases page and run it. (It's unsigned for now, so on the SmartScreen prompt click More info → Run anyway.) Then connect a database from the top-left connection switcher — see the Postgres walkthrough if you want the details.

Step 3 — Point dbclaw at Ollama

1. Open Settings → LLM provider.
2. Set Active provider to Ollama (local).
3. Set the Model to what you pulled, e.g. llama3.1:8b.
4. Leave the base URL as http://localhost:11434 (the default).

That's it — no API key field to fill, because there's no API.

Step 4 — Ask a question, fully offline

Open the Chat tab, pick your database, and ask:

What were our top 5 selling products last month by units sold?

The local model reads your schema, writes read-only SQL, dbclaw runs it against your database, and you get a table back — all on your machine. You can disconnect from the internet and it still works.

Performance tips for local models

Small local models are impressive but not magic. A few habits keep them snappy:

• Prefer a coder model like qwen2.5-coder:7b for SQL-heavy work.
• Keep chats short. Long conversations grow the context the model has to chew through every turn, which slows small models down. Start a new chat for a new topic.
• Use the Stop button. If a reply is dragging, stop it and rephrase — you don't have to wait it out.
• Give it RAM. Close memory-hungry apps; bigger models need the headroom.

What actually leaves your machine? Nothing.

With a cloud provider, dbclaw sends your question and schema (never your rows) to that provider. With Ollama, even that stays local — the model runs as a process on your own computer. Combined with dbclaw's other guarantees:

• Read-only: writes (INSERT/UPDATE/DELETE/DROP) are blocked before they reach the database.
• Keychain: database credentials live in your OS keychain, not plain files.
• Local audit log: every action is recorded locally so you can see exactly what ran.

FAQ

Do I need a GPU?

No. Smaller models run on CPU; a GPU just makes them faster. Match the model size to your RAM.

Can I switch between local and cloud?

Yes. The active provider is a setting — use Ollama for sensitive databases and a cloud model when you want extra horsepower.

My local model connects but won't produce a query.

It's almost always a non-tool-capable model. Switch to llama3.1:8b, qwen2.5-coder:7b, mistral-nemo, or command-r, and make sure ollama serve is running.