Google turns NL2SQL context tuning into a measurable hill-climbing loop

Google Cloud has documented a context-engineering agent that treats NL2SQL improvement as a repeatable evaluation loop rather than a sequence of prompt edits. The workflow can generate a golden dataset, build a baseline context set, evaluate Google’s QueryData service, analyze failures and write a revised context file alongside the original. The Cloud SQL guide was last updated September 1; the linked open-source repository’s latest tagged release is 0.7.2 from August 5. That distinction matters: this is a newly documented operating workflow, not a September package release. (Google Cloud documentation; release history)

The evaluation set comes first

The agent starts from question-SQL pairs stored in JSON. It can generate candidates from a schema, expand seed examples with synonyms and rephrasings, and optionally execute the SQL before an operator approves it for the golden set. Google’s guide is explicit about the purpose: establish a baseline and validate later context changes against ground truth. (Google Cloud documentation)

That is a stronger deployment pattern than asking whether a handful of demos “look right.” Every proposed context change has a named regression set. But teams still own the difficult part: ensuring that the questions represent real application traffic and that the expected SQL expresses the intended business answer. The agent can expand a seed set; it cannot prove that the seed set captures the business. (Google Cloud documentation)

Failures become targeted context changes

Evaluation runs QueryData over each golden question and uses Google’s Evalbench to compare generated SQL and execution results with the expected answer. The workflow writes aggregate pass/fail metrics and detailed CSV reports. Its gap-analysis stage then groups failures such as wrong columns, missing joins or unresolved fuzzy values, and proposes one of three structured fixes: a complete query template, a reusable facet such as a filter or join fragment, or a value-search query that maps user language to database values. Revised JSON is saved next to the baseline instead of replacing it. (Google Cloud documentation)

The open repository broadens that mechanism beyond PostgreSQL. Its README says the plugin supports SQL and graph-query context for AlloyDB, Cloud SQL and Spanner, and can run inside compatible coding-agent harnesses. It packages agent skills plus MCP servers, while accepting business artifacts from local files or MCP-connected sources. (GoogleCloudPlatform/db-context-enrichment)

What to verify before adoption

Google describes near-100% quality as the target for enterprise text-to-SQL, but neither the guide nor the repository publishes a cross-customer benchmark proving that result. Treat it as an optimization objective, not a measured guarantee. (Google Cloud documentation; repository)

A production trial should therefore preserve three artifacts for every iteration: the frozen golden dataset, the exact context JSON, and the detailed evaluation report. Run a held-out set that the agent did not use for gap analysis, review every newly generated SQL pair before it enters the golden set, and compare both accuracy and query latency—Google notes that choosing a value search where a template is sufficient can add latency. The documented setup also requires project-level QueryData and Cloud SQL roles, read-only database privileges, and Cloud SQL Data API access, so the evaluation harness belongs inside the same access review as the agent it is tuning. (Google Cloud documentation)