SQL generation

When to use this scenario

Natural-language-to-SQL lets analysts and product managers query databases without writing SQL. The critical difference from generic code generation is that the model must infer schema semantics — whether user_id and customer_id are the same entity, what a status enum means — from schema comments and few-shot examples, not from training data.

Input tokens are dominated by schema context (table definitions, column comments, sample rows). A realistic analytics schema runs 2–4K tokens; a large multi-tenant SaaS schema can hit 8K. Qwen-3 Coder leads open benchmarks on Spider and BIRD-SQL while costing a fraction of frontier text models, making it the default primary.

The business risk is silent correctness failure: a query that runs without error but counts the wrong cohort or joins on the wrong key. Every SQL generation pipeline needs execution sandboxing plus a result plausibility check (row count in expected range, no Cartesian joins, date filters applied) before returning results to users.

Common pitfalls

• Passing raw schema DDL without column-level descriptions — models fill gaps with plausible-sounding but wrong assumptions about column semantics
• Skipping query execution in a read-only sandbox; testing only whether the SQL parses, not whether it returns sensible results
• Assuming generated SQL is dialect-agnostic — BigQuery, Snowflake, and PostgreSQL handle window functions, CTEs, and date arithmetic differently
• Ignoring multi-turn context: when users refine queries ("now filter by last 30 days"), including prior SQL in context prevents unnecessary re-generation from scratch