Google’s QueryData makes curated SQL part of the data agent—not just its prompt

Google has documented QueryData for Cloud SQL for MySQL, giving practitioners a concrete look at how its database agent turns natural-language questions into SQL. The important part is not the chat surface. It is the context set that sits between a question and the generated query. Google’s Cloud SQL page, updated September 9, points MySQL users to a full workflow for creating, testing and integrating those context sets. (Google Cloud: QueryData for Cloud SQL for MySQL)

Context is code, not a paragraph

A QueryData context set can contain three kinds of curated database logic: complete query templates, reusable predicate “facets,” and value-search queries. Templates pair representative questions with reviewed SQL; facets encode conditions that can be composed into a query; value searches look inside database values so the agent can distinguish, for example, a city from a district or map “Heathrow” to the stored value “London Heathrow.” Google lists AlloyDB for PostgreSQL, Cloud SQL for MySQL, Cloud SQL for PostgreSQL and Spanner as supported databases. Context sets are currently creatable in four regions: us-central1, us-east1, europe-west4 and asia-southeast1. (Google Cloud: Context sets overview)

That architecture moves a large share of NL2SQL behavior into an inspectable artifact. QueryData prioritizes developer-audited templates and facets when matching a user question, then synthesizes a query from the selected material. The context is uploaded as JSON, and Google directs developers to author or extend it with Gemini CLI. This is closer to maintaining a tested query library than to hoping a model infers every business rule from schema names. (Google Cloud: QueryData overview)

The correction loop is explicit

Cloud SQL Studio exposes a “Test context set” flow. A developer asks a natural-language question, reviews the generated SQL, downloads the context file when the result is wrong, adds query pairs, uploads the revision and tests again. Once the set is satisfactory, an application calls the QueryData endpoint with the context-set ID. The request can ask for generated SQL, query results, a natural-language answer, an explanation and a disambiguation question. (Google Cloud: Test QueryData)

That is a useful production boundary: the agent can explain or disambiguate, but the reviewed SQL patterns remain separately versionable. Teams evaluating QueryData should therefore test not only answer accuracy, but also whether a context change fixes the intended question without regressing adjacent templates and facets.

Authorization still belongs in the database

Google’s accompanying security guidance uses parameterized secure views for row-level filtering. The application connects with a minimally privileged role, receives access to the secure view rather than the base table, and passes an end-user identifier when QueryData executes the request. The documented example requires Cloud SQL for MySQL 8.0.43 or later and explicitly verifies that direct reads of the base table fail. (Google Cloud: Secure application data)

The practical takeaway is straightforward: a context set improves what SQL gets written; database roles and secure views decide what that SQL is allowed to see. Deployments need both control loops before conversational querying is ready for real users.