Why local-first analytics wins for teams that can't share their data

This is a design note about how DataAgent is built and why. It is not a feature announcement, and it does not describe a future release.

Cloud BI made everyone faster — until the compliance review. For a growing set of teams, the request "just put it in Looker" now triggers a six-week security questionnaire, and the answer is often no. Not because the tool is bad, but because the rows are not allowed to leave the building.

DataAgent starts from the opposite premise: your data already lives on your machine, and it should stay there. The warehouse is an embedded DuckDB file, the LLM is one you choose (including a fully local Ollama model), and the whole product ships as one self-contained Windows app you can read top to bottom.

Why "just use the cloud" stops working

The hidden cost of cloud analytics isn't the license — it's the data gravity. Every upload creates a copy: in a bucket, in a query cache, in someone's notebook export. For healthcare, finance, government, and any team handling customer PII, each copy is a new thing to audit. At some point the questionnaire arrives, and the honest answer to "where does the data go?" has to be: nowhere else.

Local-first sidesteps the review because the data flow is trivially simple. There is no ingestion pipeline to a vendor, no third subprocessor list, no egress to model providers — unless you explicitly configure one.

The stack that makes it possible

Three pieces do all the heavy lifting:

• DuckDB — an embedded analytical engine. No server, no cluster; the warehouse is one file with columnar speed.
• Local (or chosen) LLMs — Ollama on your laptop, or a hosted provider if your policy allows it. Swap with a config file, not a migration.
• FastAPI — a single backend process serving the web UI, the chat stream, SQL execution, and export.

Trusting the SQL you didn't write

An assistant that writes queries is only useful if you can audit them. The query behind an answer travels with the answer in the API response, and every executed query is written to the audit log — there is no hidden semantic layer and no vendor-defined "metric store" you can't inspect. On the security side, the rules are deliberately boring:

• SQL is parameterized at execution; generated queries run read-only against the warehouse.
• Everything crossing the API boundary is validated with schemas before it touches business logic.
• Secrets (JWT keys, DB credentials) live outside git and are never surfaced into the model context or logs.

"Boring security is the point. If the data plane can be explained in one paragraph, the audit writes itself."

The honest trade-offs

Local-first is not free. A laptop DuckDB won't match a warehouse cluster on a 5-billion-row join — you trade elastic scale for absolute data control. Model quality on fully local weights trails the best hosted models on tricky reasoning tasks. And collaboration means sharing a dashboard file, not a live URL.

There are limits that are not trade-offs but simply the state of this build, and they are worth stating plainly:

• The whole warehouse is one DuckDB file, and DuckDB allows a single writer per file. Two processes writing at once is an error, not a queue.
• Live database connections are SQLite, PostgreSQL and MySQL. There are no cloud object-store connectors — no S3, no GCS, no Azure Blob.
• The PDF export is basic: a plain text summary, because the HTML-to-PDF renderer is not bundled. Excel, PowerPoint, HTML, Markdown, CSV, Parquet and the Power BI .pbix are the fully formatted exports.
• The release is not code-signed yet, so Windows SmartScreen shows "Unknown publisher" until a certificate is in place.
• Single sign-on and row-level security are implemented but ship disabled. Switch them on deliberately rather than assuming they are running.

For the teams we built this for, the ones whose alternative is "no analytics at all", those trade-offs are easy. Control over rows beats scale you were never allowed to use.

Get started

Install is one .exe. Register your user, load a file, ask a question, read the SQL, ship the chart. If DataAgent doesn't fit your workflow, the FAQ covers the usual doubts — and the whole thing is open source under AGPL-3.0, so you can check our answers before you trust them.

Download DataAgent Read the FAQ