📰 AI NewsDataIntermediate✨ AI-assisted

BigQuery Adds Natural Language Comments to SQL Queries

WittyTech Daily··4 min read
#bigquery#gemini#sql#google-cloud

Google just turned BigQuery natural language SQL from a chatbot side quest into a built-in editor feature. The capability is called Comments to SQL, it lives inside BigQuery Studio as a preview, and Google's own docs for it were still being updated as recently as this month. The pitch is simple: write a plain-English comment where a clause should go, and Gemini fills in the real SQL around it, with a diff you review before anything runs.

What "vibe querying" actually means here

The internet has taken to calling this vibe querying, and the name fits better than most AI marketing terms do. You don't open a separate chat window and ask for a finished query. You write normal SQL and drop natural-language comments, wrapped in /* */ or #, exactly where you'd otherwise have to remember the right column name or window function syntax:

SELECT
  subscriber_type,
  /* the day of week of trip start ordered longest to shortest */
FROM `bigquery-public-data.austin_bikeshare.bikeshare_trips`

Highlight the query, click the Gemini icon in the editor's gutter, and choose Convert comments to SQL. Gemini expands the comment into working SQL and shows it in a comparison pane next to your original. You click Insert to accept it or Refine to describe what you actually meant and try again. Google says the feature understands surrounding SQL context, so it works across SELECT, FROM, WHERE, ORDER BY, GROUP BY, WINDOW, and PIVOT clauses, and you can mix several natural-language expressions in one statement for multi-table joins or ranked window queries.

Two prerequisites worth knowing before you demo this to a customer: your account needs the roles/cloudaicompanion.user ("Gemini for Google Cloud User") IAM role, and only English-language prompts are supported right now.

Why this matters for bigquery data analysis work

If you're an FDE, you've probably sat next to an analyst who knows exactly what question they're asking but blanks on LAG() versus RANK() syntax, or a customer stakeholder who can describe a filter in English but has never written a WHERE clause. Comments to SQL doesn't replace that person's judgment, it removes the syntax tax. The query still runs under the user's own BigQuery permissions, row-level security and all, and nothing executes until a human clicks Insert and then runs it themselves.

That matters more than it sounds. A chatbot bolted onto a warehouse tends to generate a full query from a prompt and hand it back as a black box. Comments to SQL keeps the human inside the actual SQL editor, writing real structure and only outsourcing the parts they're unsure about, with a diff as a checkpoint. That's a meaningfully smaller trust surface for anything touching production data.

The timing lines up with a broader push. Google's BigQuery gen AI functions update moved AI.GENERATE and AI.GENERATE_TABLE to general availability, added AI.EMBED and AI.SIMILARITY in preview for embeddings and semantic similarity, and brought Gemini 3.0 support to those functions. Comments to SQL isn't part of that same announcement, but it's the same direction: fewer trips out of BigQuery to get AI-assisted analysis done.

Where not to trust it yet

It's a preview feature, so treat generated WHERE clauses and joins the way you'd treat a junior analyst's first draft: check the row counts before you ship a dashboard off it. A misread comment on a filter clause won't throw an error, it'll just quietly return the wrong rows, and a diff view only helps if someone actually reads it instead of reflexively clicking Insert. For anything feeding a customer-facing report or a billing pipeline, keep a human review step regardless of how good the diff looks.

What to do Monday morning

Turn on "Gemini in SQL query" auto-generation in a sandbox project, grant yourself the Gemini for Google Cloud User role, and run your team's five most annoying recurring queries through Comments to SQL. See where it nails the syntax and where it guesses wrong on column names, then decide whether it's ready to hand to the customer's analysts or just useful for your own team's velocity. Either way, an FDE who can show a client's data team a working diff of English turning into SQL, live, in their own editor, has a better pitch than one hour of chatbot demos.

The practical upside for anyone shipping AI into a customer's data stack: this is one more place where you can lower the barrier to entry for the customer's own team without giving up the review step that keeps production queries honest.

← More in Data