Supervised fine-tuning
SQL generation over your own schema
How do I fine-tune a model to write correct SQL for my database?
Train on question-and-query pairs from your actual query logs. General text-to-SQL models know SQL; they do not know that your `users` table is deprecated and everything now joins through `accounts`.
| Objective | Supervised fine-tuning |
|---|---|
| Dataset shape | Natural-language question in, verified SQL out, with the schema in context. |
| Metric that decides it | Execution accuracy — does the query run and return the right rows — not string similarity to a reference query. |
| Cheapest starting point | Qwen3 8B on RTX 4000 Ada$0.09 per GPU-hour |
Text-to-SQL fails on real schemas for reasons that have nothing to do with SQL competence. The model does not know which of your three date columns is authoritative, that a table was deprecated eighteen months ago, or that a particular join needs a filter to avoid double counting. Those are facts about your organisation.
Mine your query logs. Analyst-written queries that ran successfully and were reused are a far better training signal than anything hand-written for the purpose, because they encode the conventions that nobody documented.
Evaluate by executing. String similarity to a reference query is actively misleading — two very different queries can return identical correct results, and two nearly identical queries can differ by a WHERE clause that changes everything.
The mistake to avoid
Evaluating with string similarity. It rewards queries that look like the reference and punishes correct queries that took a different route.
Models to start from
In order. Start at the top and move down the list only if the evaluation gate says you have to — the smallest model that clears your bar is the one you pay for on every request forever.
Before you deploy it
Whatever the metric above says in isolation, the deployment decision is comparative: is this better than what is running today? Gate the candidate against the incumbent, blinded, on held-out cases from your own traffic. A fail is a cheap answer to an expensive question.
Frequently asked questions
Do I still need the schema in the prompt?
Yes. Schemas change; put them in context so an update does not require retraining. What the fine-tune contributes is convention and judgement, not table names.
What about write queries?
Do not. Generate read queries and keep writes behind reviewed, parameterised code paths.
Start with Qwen3 8B
Upload your dataset, read the validation report, and forecast the run before anything is leased.