Verified SQL examples are not portable across Microsoft, Google and Snowflake data agents
The same question-and-query pair can act as a retrieved hint, a composable blueprint or a governed semantic-model asset. Treating those roles as interchangeable is a migration trap.
A team moving an NL2SQL workload between enterprise platforms can carry over its question-and-SQL pairs and still change the system’s behavior. Microsoft, Google and Snowflake all let operators provide curated examples, but their documentation assigns those examples materially different jobs.
Microsoft: examples are retrieved hints
In Microsoft Fabric Data Agent, SQL and KQL sources accept natural-language/query pairs. The service retrieves the most relevant examples with vector similarity, then uses them alongside selected schema and instructions. Microsoft separately validates generated SQL and KQL against the schema entities that the operator approved.
That makes an example part of retrieval-time guidance, not the whole authorization boundary. Fabric also handles Power BI semantic models differently: instructions and Verified Answers are managed through Power BI’s Prep for AI surface rather than as ordinary data-source instructions. One product therefore already has multiple example contracts depending on the source type.
Google: blueprints are structures that facets can modify
Google’s preview QueryData service puts validated question/SQL pairs inside a broader context set. Its query blueprints define canonical intent-to-SQL mappings, but query facets contribute reusable predicates and value searches map informal phrases to actual column values. QueryData can also return a clarification question when an input is ambiguous.
A Google blueprint is therefore not merely a nearest-neighbor demonstration. It is one component in a synthesis process that can resolve values, combine filters and ask for disambiguation before generating SQL. Migrating only the paired examples would omit two other documented context primitives.
Snowflake: verification is a governed semantic-model asset
Snowflake’s Cortex Analyst Verified Query Repository stores questions and SQL inside a semantic model or view. The SQL must reference logical table and column names from that model rather than the underlying physical names. Snowflake’s documented workflow asks a person to inspect, edit, execute and test the generated query before saving it as verified; optional fields record who verified it and when.
Cortex Analyst can reuse a relevant verified query for a similar question, and the API confidence information can show which verified query contributed to a response. The repository is thus both a grounding mechanism and a provenance-bearing review artifact.
The migration test
Before transferring an example library, ask four questions: How is an example selected? Can other context rewrite or compose it? Which names does its SQL bind to? What review and provenance survive deployment?
A high-quality pair can be useful on all three platforms, but it is not the same control object. Microsoft treats examples as retrieved guidance within a source configuration; Google makes blueprints composable with facets and value resolution; Snowflake binds verified SQL to logical semantic-model names and a human review trail. Port the intent and tests—not just the YAML or JSON rows.
sources
- Microsoft Fabric: Add a data source to Data Agentlearn.microsoft.com
- Google Cloud: QueryData data agent overviewdocs.cloud.google.com
- Snowflake Cortex Analyst Verified Query Repositorydocs.snowflake.com
comments · 0