Where your schema and your questions go, product by product

Every tool that turns a question into SQL has to read your schema, and most of them have to send it somewhere to do that. For an organisation that may not move its data, this is the first question to settle and usually the last one that gets asked. Here is what each product does, and what I could not confirm.

What leaves the machine, and when

Three things can travel: the schema, the question, and the rows that come back. A product can be careful with one and careless with another, so they are worth separating.

The business intelligence suites

These are not alternatives for an organisation that cannot move data, for a reason that has nothing to do with their quality. They cannot be installed and run without their service.

• Power BI Copilot has no separate licence. It requires paid Fabric capacity at F2 or above, or Premium P1 or above, and consumes capacity units as it is used.
• Tableau Agent requires Cloud+ or Tableau+. The dashboards beta consumes Data 360 credits.
• ThoughtSpot Spotter is available on the Pro plan at 50 USD per user per month, and per-user plans cap it at 25 queries per user per month.

What I could not confirm

I am stating this rather than writing around it. For Power BI Copilot, Tableau Agent and ThoughtSpot Spotter, I could not establish from the sources I found where the natural-language request and the data are actually processed, or in which region. Those products are delivered as services, so something clearly leaves the tenant, but the specifics belong in each vendor’s own data residency and AI processing documentation, and I have not verified them. If that distinction matters to your decision, read their documentation rather than this page.

I also have not independently tested the privacy behaviour of AskYourDatabase or DataLine. The statements above are taken from the vendor’s pricing page and the project’s README respectively, which is the strongest evidence available without instrumenting the network, and weaker than a measurement.

Why a local model only became reasonable recently

Until recently the honest answer to “can this run on a laptop” was that it could, badly. That changed because specialised models got good at a size that fits in memory. Snowflake’s Arctic-Text2SQL-R1-7B reports 68.9% execution accuracy on BIRD dev at seven billion parameters, under Apache-2.0. For comparison, my own measurement of a general-purpose Qwen2.5-Coder-32B with self-correction on the same split was 51.63%, published in arXiv:2606.29733.

The useful model stopped being the large one. A specialised model four and a half times smaller is the reason a product like this can exist without a cloud behind it, and the reason every product built a year ago has a cloud behind it.

What privacy costs here, stated plainly

Keeping everything on the machine is not free of consequences, and I would rather name them than let them be discovered.

• The model is slower than a cloud model, because it runs on your hardware rather than on an accelerator in a data centre. The figures will be published with the ranking, measured on named hardware.
• The model is smaller than a cloud model, and on the hardest questions that shows. This is why accuracy is measured and published rather than asserted.
• There is no telemetry, so I learn nothing about usage. That is the cost of the promise, and it cannot be bought back with anonymous statistics without breaking the promise. Feedback happens when you choose to send it.
• A read-only database role is still your responsibility. The application runs only SELECT, parses every query before executing it, and adds a row limit, but a role with write permissions is a risk the application cannot remove for you.