QueryCraft: Modular SQL Generation Framework

• QueryCraft is a modular SQL generation framework that integrates schema internalization, conversational parsing, prompt-budget optimization, query-by-example, and imperative-to-SQL lifting to produce executable and semantically correct SQL.
• It employs a two-phase fine-tuning pipeline with schema memorization and Pareto-front prompt optimization, achieving high execution success (98.4%) and over 99% reduction in input tokens.
• The framework’s layered design supports multiple entry points—natural language queries, conversational context, example-driven intent, and code synthesis—adapting efficiently to diverse operational constraints.

QueryCraft denotes a systems view of SQL generation in which multiple query-acquisition paradigms are composed around a common objective: producing executable, semantically correct SQL while reducing schema burden, conversational ambiguity, prompt cost, and application-level inefficiency. In the cited literature, the relevant mechanisms include a two-phase fine-tuning pipeline that internalizes a database schema behind a short schema_id, a context-dependent parser that learns to internally reformulate conversational questions, a Pareto-front optimizer for prompt accuracy and token cost, an abductive query-by-example interface, and an overview procedure that lifts imperative ORM code into SQL [(Soni et al., 25 Mar 2026); (Xiao et al., 2022); (Kumar et al., 3 Jun 2026); (Fariha et al., 2020); (Cheung et al., 2012)].

1. Architectural scope

The QueryCraft framing spans at least five technically distinct capabilities. First, it can answer natural-language questions against a known relational schema by mapping user utterances to SQL. Second, it can preserve conversational state across turns, including co-reference, ellipsis, and user focus change. Third, it can optimize prompts when prompt tokens remain part of the inference path. Fourth, it can infer intent from examples rather than from formal query text. Fifth, it can derive SQL from imperative application logic and thereby push computation from application code into the database engine.

Capability	Mechanism	Source
Schema-aware text-to-SQL	Two-phase fine-tuning with schema_id recall	(Soni et al., 25 Mar 2026)
Context-dependent parsing	CQR, schema grounding, AST consistency	(Xiao et al., 2022)
Accuracy-cost prompt search	Pareto-front optimization over $p$ and $c$	(Kumar et al., 3 Jun 2026)
Query by example	Abductive ranking over semantic properties	(Fariha et al., 2020)
Imperative-to-SQL lifting	Invariant and postcondition synthesis over FORs	(Cheung et al., 2012)

Taken together, these components define QueryCraft less as a single algorithm than as a query-engineering stack. A plausible implication is that QueryCraft is most naturally deployed as a modular system in which natural-language parsing, schema grounding, prompt budgeting, user-intent capture, and code-level query extraction are selected according to the interaction mode and operational constraints.

2. Schema internalization and minimal-prompt text-to-SQL

The most explicit QueryCraft integration recipe is given by the two-phase supervised fine-tuning method in "Schema on the Inside" (Soni et al., 25 Mar 2026). The setting is industrial text-to-SQL for CriQ, a sister app to Dream11, India's largest fantasy sports platform with over 250 million users. The model is Qwen 3 8 B parameters, a decoder-only multihead transformer with LoRA adapters. The schema comprises 35 tables, approximately 150 columns, and approximately 200 foreign-key links. Training uses 11 000 seed user queries to bootstrap ground-truth generation, and the total training corpus is 245 000 examples.

Phase 1, termed schema pre-training, has two objectives: teaching the model how to write SQL in context and internalizing schema structure. Its data consist of 80 000 full-context examples, each with a 17 000-token prompt containing the full schema, domain notes, and a natural-language question, plus 15 000 explicit memorization examples that map a request such as “Give me full schema details for database_id = ‘my_db_v1’.” to the full DDL text. Training uses LoRA adapters with rank $r = 64$ and $\alpha = 128$ injected into q_proj, k_proj, and v_proj, AdamW with learning rate $2 \times 10^{-5}$ and weight decay $0.01$, cosine decay, batch size 256 across $8\times$H100 GPUs, 3 epochs, and a 20 480-token context window. Phase 2, task-specific supervised tuning, continues from the Phase 1 adapter and trains on 150 000 minimal-prompt examples of the form “User Query” plus Database_id, with the matching SQL as output; it keeps the optimizer and hyperparameters, reduces the context window to 1 024 tokens, and runs for 2 epochs (Soni et al., 25 Mar 2026).

The central mechanism is the assignment of a short unique ID such as my_db_v1. During Phase 1, the model learns to associate that ID with the full table/column graph via the memorization examples. During Phase 2, it is forced to generate correct SQL using only the schema ID as a trigger. The stated result is that the model “recalls” the entire schema from its parameters and produces schema-aware SQL without reading the DDL in the prompt.

The reported deployment consequences are concrete. Input tokens fall by over 99%, from a 17k-token baseline to fewer than 100. Execution success reaches 98.4%, compared with 95.6% for a prompt-engineered baseline using Google's Gemini Flash 2.0. Semantic accuracy reaches 92.5%, compared with 89.4% for the same baseline. Cost is expressed as $C_{\mathrm{base}} = T_{\mathrm{baseline}} \times c$ and $$C_{\mathrm{ft}} = T_{\mathrm{fine\text{-}tuned}} \times c$$, yielding more than 99% reduction in per-query spend. With latency assumed to scale roughly linearly with prompt length, the text gives $L_{\mathrm{base}} \approx 2\,\mathrm{s/query}$ for 17k tokens and $c$0 plus fixed overhead.

The paper also states several operational constraints that are directly relevant to QueryCraft. The two-phase curriculum is essential: skipping Phase 1 yields only approximately 75% execution success, and omitting explicit schema-memorization examples drops execution to approximately 87%. The schema must be relatively static, since major schema changes require retraining. For integration, the recommendation is to pre-train a small suite of adapters, one per distinct schema, each keyed by a short ID, send only the question plus schema_id at query time, and monitor execution and semantic metrics in production.

3. Conversational dependency, internal reformulation, and latent-state alignment

For multi-turn QueryCraft behavior, the relevant design is CQR-SQL, which addresses context-dependent text-to-SQL in the presence of co-reference, ellipsis, and shifting user focus (Xiao et al., 2022). The method begins from the observation that existing approaches often exploit history context or previously predicted SQL while neglecting explicit comprehension of schema and conversational dependency. It also argues that two-stage pipelines of conversational question reformulation followed by text-to-SQL suffer error propagation and ignore alignment between the intermediate reformulation and final parsing.

The model therefore combines schema-enhanced recursive CQR with joint parsing. At turn $c$1, the reformulator consumes all prior utterances together with the full table and column names of schema $c$2, and also conditions on its own previous reformulation $c$3. The turn-level CQR loss is

$c$4

A self-training loop expands a small manually annotated in-domain CQR set into a larger pseudo-CQR dataset by retaining only reformulations that allow a pre-trained single-turn parser to recover the correct SQL in its beam.

Two consistency mechanisms are then imposed. The schema grounding consistency task prepends a latent-variable token [Z] to the input, runs a shared Relation-Aware Transformer encoder, and uses the final hidden state at [Z] to predict the bag of used schema items. It adds both bag-of-words supervision on the gold schema items and a symmetric KL penalty between schema-item distributions induced by the original context question and its self-contained reformulation. The tree-structured SQL parsing consistency task uses a tree-structured LSTM decoder whose actions are ApplyRule[R], SelectColumn[i], and SelectTable[j]; it adds symmetric KL penalties so that the action distributions match step by step between the contextual input and the reformulated input. The total loss at turn $c$5 is

$c$6

The architecture uses a shared RAT encoder, a latent [Z] token as a dialog-level summary embedding, and a single tree-structured LSTM decoder. At training time, the decoder attends separately to the RAT encodings of the contextual question sequence and the reformulation; at inference, it consumes only the contextual encoding. The paper characterizes this as learning to “internally reformulate” without calling an external CQR at test time.

The empirical basis comes from SParC and CoSQL. SParC contains 4 298 dialogs with 3 034 train, 422 dev, and 842 test dialogs, averaging approximately 3.0 turns per dialog. CoSQL contains 3 007 dialogs with 2 164 train, 293 dev, and 551 test dialogs, averaging approximately 5.2 turns and including system responses. Evaluation uses Question Match and Interaction Match. On the dev set with an ELECTRA encoder, CQR-SQL improves SParC from 64.9/46.5 to 67.8/48.1 and CoSQL from 56.6/23.9 to 58.4/29.4. Ablations show that removing schema grounding, removing SQL-consistency, or removing both consistency tasks reduces performance. For QueryCraft, the immediate significance is robustness to conversational compression: terse turns need not explicitly restate referents, schema entities, or prior intent.

4. Prompt-budget optimization and Pareto-front search

When QueryCraft still depends on prompts rather than on fully internalized schema knowledge, prompt optimization becomes a budgeted search problem. CRAFT formulates this as a bi-objective search over accuracy $c$7 on a validation set and cost $c$8, defined as the number of prompt tokens excluding examples and model outputs (Kumar et al., 3 Jun 2026). The target is the Pareto-optimal set

$c$9

The paper contrasts this with scalarization,

$r = 64$0

and names the failure mode scalarization collapse, namely that a fixed weight often recovers only a narrow region of the true front.

CRAFT maintains a population of size $r = 64$1 over $r = 64$2 rounds. Each round has three main stages. Generation uses an accuracy-oriented refinement module and a cost-oriented condensation module. Both operate over a structure-aware critic-actor pipeline: refinement proposes Update, Insert, Delete, Merge, and Reorder, while condensation targets a random compression ratio $r = 64$3B = 2k$ calls on candidates that lie on or near an optimistic front computed from upper-confidence-bound accuracy estimates and normalized token cost. NSGA-II retention performs fast non-dominated sorting on validated candidates and uses maximin spread to keep a population that spans the trade-off curve.

Across six benchmarks—BeaverTails, GoEmotions, and four BIG-Bench Hard tasks—the reported pattern is consistent. Accuracy-only, cost-only, and weighted-sum baselines each concentrate in narrower regions, whereas CRAFT recovers both the high-accuracy, high-cost end and the low-cost, moderate-accuracy end of the front. The method wins the overall composite rank across all six tasks, places first or second on every metric across almost every dataset, and shows steady front improvement over 12 rounds on DisambiguationQA (Kumar et al., 3 Jun 2026).

A plausible implication is that QueryCraft can use two distinct optimization regimes. Where schema internalization is feasible, prompt tokens can be collapsed to a question plus schema_id. Where prompt engineering remains necessary, the design objective should not be a single “best prompt” but a retained Pareto front from which deployment can later choose an operating point. The limitations in CRAFT remain relevant: all experiments are on English classification and short-answer reasoning, open-ended generation remains untested, behavior under very poor or adversarial initial prompts is unexplored, and safety rests with the chosen evaluation score rather than with the optimizer itself.

5. Example-driven intent discovery

QueryCraft need not be restricted to natural-language interfaces. SQuID shows a different access mode, Query by Example, in which user intent is inferred abductively from tuples rather than from a formal query string (Fariha et al., 2020). The formal objective is

$r = 64$4

where $r = 64$5 is the underlying relational database, $r = 64$6 is a small set of user-provided example tuples, and $r = 64$7 is the space of SQL SELECT queries expressible with common operators. By Bayes’ rule, $r = 64$8, with $r = 64$9 when all examples satisfy $\alpha = 128$0 and $\alpha = 128$1 otherwise. Candidate queries are represented as conjunctions of semantic properties, and the score is approximated in log space by

$\alpha = 128$2

so rarer properties receive higher weight.

The system has an offline and an online phase. Offline, it crawls the schema and full content of $\alpha = 128$3, derives semantic properties $\alpha = 128$4, and stores global statistics $\alpha = 128$5. Online, it parses the user examples, retrieves all properties true for every example, discards overly common properties, forms small conjunctive combinations, scores candidate queries by the sum of $\alpha = 128$6, keeps top-ranked queries satisfying $\alpha = 128$7, executes the top result, and exposes iterative feedback through the GUI.

The evaluation compares SQuID with hand-written SQL in two studies. In a controlled experiment with $\alpha = 128$8, participants solved four data-exploration tasks over an IMDb snapshot, with within-subject counterbalancing between SQuID and SQL. SQuID outperformed SQL on precision for all tasks and on $\alpha = 128$9 for all tasks, with highly significant gains on the subjective tasks. It was on average approximately 200 seconds faster and required approximately 4 fewer query attempts. In a qualitative interview study with $2 \times 10^{-5}$0, thematic coding identified schema complexity, semantic formalization, syntax errors, interactive refinement, domain-knowledge limits, and trust and explainability as salient factors.

For QueryCraft, this suggests an additional interaction layer for cases where users cannot or do not wish to specify predicates linguistically. The strongest evidence concerns subjective predicates. The text notes that SQL users had to choose arbitrary thresholds such as “at least one comedy” versus “$2 \times 10^{-5}$1 comedies,” whereas SQuID inferred such thresholds automatically from examples. The same study, however, also shows that examples do not eliminate all user burden: users still needed basic familiarity to propose initial examples, and trust could be improved by exposing synthesized SQL or the semantic properties and weights that drove inference.

6. Program synthesis, relational lifting, and operational constraints

A further QueryCraft function is SQL inference from application code rather than from end-user input. QBS addresses this by identifying fragments of imperative logic that can be pushed into SQL queries (Cheung et al., 2012). Its formal substrate is the theory of finite ordered relations, in which an ordered relation is a finite sequence of records equipped with operators for selection, projection, join, aggregation, top, sort, and unique. The theory is intended to preserve not only content but also ordering and duplicate semantics, so that synthesized SQL is semantically identical to the original imperative fragment.

The algorithm computes verification conditions in Hoare style while leaving loop invariants and the final postcondition unknown. It then synthesizes these predicates from a bounded grammar of relational expressions. Candidate invariants and postconditions are tested by a bounded interpreter in a counter-example-guided inductive synthesis loop, implemented with Sketch, and then discharged universally by Z3. Once a validated postcondition of the form R_res = E_res is found, the system rewrites $2 \times 10^{-5}$2 into a normal form and translates it recursively into SQL through syntax-directed rules for base queries, cross-products, selections, projections, sorting, LIMIT, and aggregation.

The paper evaluates QBS on 40 code fragments extracted from over 120k lines of open-source Java/Hibernate code. It reports successful conversion of all 40 loops implementing selections, projections, joins, and aggregates. Simple projections and selections are solved in less than 1 minute each; joins and aggregations can take up to 10–40 minutes in worst cases. The relevance to QueryCraft is architectural rather than interactive: it extends query generation from user-facing interfaces to application optimization, allowing imperative list-processing code to be replaced by a single ORM call executing synthesized SQL.

Across the full QueryCraft stack, the documented limitations are heterogeneous but structurally aligned. Schema-internalized text-to-SQL requires a relatively static schema, and major schema changes require retraining (Soni et al., 25 Mar 2026). Prompt-front optimization leaves open-ended generation untested and does not itself define safety; the reward defines safety (Kumar et al., 3 Jun 2026). Query-by-example still requires enough domain knowledge to supply useful initial tuples and would benefit from stronger explainability (Fariha et al., 2020). Program synthesis can incur interactive-to-batch runtimes depending on query complexity (Cheung et al., 2012). A plausible implication is that QueryCraft is best treated as a layered system with multiple entry points—natural language, conversational context, examples, and code fragments—rather than as a single universal parser.