Ask your BigQuery warehouse questions in plain English

I want an app that turns plain English questions into Google BigQuery queries, shows the query and what it will cost before anything runs, and never runs anything until a human clicks Run. The audience is non analysts: people who know the business question but not SQL. The data team has to be able to trust what is being fired at the warehouse, so hard read only guardrails and a full audit trail are part of the core product, not an afterthought.

The main page is the Ask screen. At the top there is a scope picker: a handler calls BigQuery List Datasets for the connected project to populate the dataset list, then BigQuery List Tables for each dataset the user selects, and BigQuery Get Table for the tables that end up in scope so the model gets real column names, types and descriptions rather than guesses. Below the picker is a plain text box where someone types a question like "how many trial signups converted to paid last month, broken down by plan". Read each dataset's location from List Datasets and reuse it on every job, otherwise cross region queries fail with a not found error.

When they click Ask, a handler sends the question plus the collected schemas to Groq Create Chat Completion and asks for a single GoogleSQL SELECT statement with fully qualified backticked table names, useLegacySql false, and a sensible LIMIT. Groq is the right engine here because drafting and redrafting is where latency is felt: the first draft should feel instant and a wrong draft should be cheap to fix. Render the SQL on screen in a read only code block with a "Regenerate with a hint" box so the user can nudge it ("only paid plans", "group by week") and get a fresh draft in a couple of seconds.

Before anything else happens, run the draft through a hard guardrail check on the server, not just in the UI. Reject anything that is not a single SELECT or WITH ... SELECT statement: no INSERT, UPDATE, DELETE, MERGE, TRUNCATE, CREATE, DROP, ALTER, GRANT or EXPORT, no scripting, no multiple statements chained with semicolons. If the model returns something that fails the check, show the rejection reason on screen and send it back to Groq for a redraft rather than silently patching it. The BigQuery connection should be set up with read only scope so the guardrail is belt and braces, not the only line of defence.

Then price it. A handler calls BigQuery Insert Job with a configuration.query body and configuration.dryRun set to true, and reads totalBytesProcessed off the returned statistics. BigQuery returns these numbers as JSON strings, so parse accordingly. Show the estimate next to the SQL in human units (GB or TB) plus a rough dollar figure using a per terabyte rate the admin sets. Two thresholds, both admin configurable: a warn line where the Run button gets a loud confirmation stating the scan size, and a hard ceiling above which Run is disabled entirely with a message telling the user to narrow the date range or the dataset scope. If the dry run comes back with a SQL error, surface the BigQuery error message and offer a one click fix that sends the error back to Groq.

Nothing runs automatically. The Run button is the only thing that executes. On click, a handler calls BigQuery Run Query (Synchronous) with the approved SQL and the dataset location. If the response comes back with jobComplete false, keep the jobReference and poll BigQuery Get Query Results until it completes; for anything expected to be slow, use Insert Job plus Get Query Results instead. Zip the returned row cells back to the schema field names and render a proper result table with column headers, sorting, and a CSV download.

Under the table, show a two line plain English readout. Send the SQL, the column schema and the first rows (capped so the payload stays small) back to Groq Create Chat Completion and ask for at most two sentences on what the numbers actually say, for example "Conversions were 312 last month, up 18 percent on the month before. Almost all of the growth came from the Pro plan." No hedging, no restating the question back.

Anything good should be reusable. A Save to library button stores the question, the final SQL, the datasets in scope and a short title into a shared library that everyone in the workspace can see. The Library page lists saved questions with who saved them and when they were last run, and each one has a Run button that goes back through the same dry run estimate and then waits for a human click, so the same weekly questions get rerun by anyone without rewriting anything. Saved questions can be edited and re-saved.

A History page logs every run: who asked, the question, the exact SQL that ran, the estimated and actual bytes scanned, the estimated cost, the duration, and whether it succeeded. Log blocked attempts too, including which guardrail blocked them, because that record is what makes the data team comfortable. Let people filter by person, by dataset and by cost, and show a running total of estimated spend for the current month at the top.

From any result, a Share to Slack button posts the question, the two line readout and the top rows as a formatted table into a channel the user picks, using Slack Bot Send a Message. Include the scan size in the message so the channel sees the cost alongside the answer.

Every result also has an Investigate this button that hands the question to a background agent defined inside the app. The agent takes the original question, the SQL and the result set and does what an analyst would do next: draft two to five follow up queries that break the number down (by segment, by week, against the prior period, filtered to the outlier rows), run each one through the same non SELECT rejection and the same dry run cost check with Insert Job in dryRun mode before executing it with Run Query (Synchronous), and stop early if it hits the admin's bytes budget for a single investigation. It then writes a short findings note, three to six bullets covering the numbers that mattered plus one line on what it could not determine, and saves that note back into the app so it shows on the question's page and in a Findings list. Show the agent's progress while it runs and list every query it ran with its own cost, so an investigation is exactly as auditable as a manual run.

An admin settings page holds the knobs: which BigQuery project to use, which datasets are selectable, the warn threshold and the hard bytes ceiling, the per investigation bytes budget, the dollars per terabyte rate used for cost display, and the default Slack channel. Everyone else sees these as read only context on the Ask screen so people know what the limits are before they run into them.

Design wise this should feel like a calm internal tool rather than a BI product. Stack the question box, the generated SQL and the cost estimate in one column so the read before you run flow is impossible to miss, and give the result table the full width below it.