Ask in plain language. It answers from your Mac.
Taula starts a llama.cpp server on your machine and runs a small open model against it. The assistant can list tables, describe them, sample rows and run read queries on its own. Anything that would write comes back as a proposal, in SQL, for you to approve.
A tool loop, with the pen held back.
The model does not get a connection string. It gets a small set of tools, each one implemented by Taula, and the read tools are the only ones that touch the database without you.
| Tool | What it does | Needs your approval |
|---|---|---|
list_tables | Tables and views, grouped by schema. | No |
describe_table | Columns, types, primary key, indexes, foreign keys. | No |
sample_rows | A handful of rows, so it can see the shape of the data. | No |
run_query | A read-only SELECT, capped in rows. Write keywords are rejected at any depth. | No |
top_queries | The ten most expensive statements from pg_stat_statements, when the extension is installed. | No |
remember_fact | Stores a durable note about this database, such as "amounts are in cents". | No |
propose_write | A single INSERT, UPDATE, DELETE or DDL statement, shown to you as SQL. | Yes |
propose_plan | A multi-step change, listed step by step, run only after you approve it. | Yes |
Proposals go through the same guardrails as the query editor, so a DELETE without a WHERE still asks twice.
No key to paste. Nothing to send.
On first use Taula finds llama-server (a setting, then Homebrew, then your PATH), downloads a single model file, and starts the server with a health check. From then on it is a process on your Mac. Your schema, your rows and your questions stay there.
- Default model: Qwen3 4B, quantized, a few gigabytes once. Any GGUF that llama.cpp can run will do; the spec is a setting.
- Streaming. Tokens and tool calls stream in as they are produced, so you see it think and can stop it.
- Hosted is optional. Prefer a larger model? Add an Anthropic key in Settings. It goes in the Keychain and is used only when you pick that model.
It learns your database, and only yours.
When the assistant works out something durable, it can store it as a fact tied to that connection: which column is the real customer id, which timestamps are UTC, which table is a view of another. Facts are plain JSON on disk, capped at 100 per connection, and you can edit or delete them.
Conversations persist too. Close Taula, reopen it, and the chat for each connection is where you left it, including a proposal you had not decided on.
What a 4B model is good at, and what it is not.
A local model this size is excellent at the unglamorous middle of database work and unreliable at the hard end. Taula is built around that, not in denial of it.
Where it earns its keep
- Finding things. "Which tables reference customers?" is a tool call, not a guess.
- Everyday SELECTs. Joins across a foreign key, filters, grouping, ordering.
- Finishing your line. Ghost text is a short completion, the task a small model handles best.
- Fixing a failed statement. Given the real error, it corrects the real mistake most of the time.
Where you should read carefully
- Window functions and deep subqueries. Often right, sometimes confidently wrong.
- Engine-specific syntax. It knows Postgres better than D1 quirks.
- Anything that writes. Which is why every write is a proposal you read first.
Taula ships an execution-graded eval corpus for its own prompts, and improvements are measured against it. A prompt fix moved ghost-completion accuracy from 73% to 87% on the corpus; that number is in the repository, not in a slide.
What you need for the local assistant.
brew install llama.cpp, or point Taula at any llama-server binary in Settings.Everything else in Taula works without the assistant. The grid, the editor, the diffs and the MCP server never need a model.
Ready when you are.
One payment, every update, no subscription. Download the DMG, add a connection, and you are reading rows in under a minute.