SQL-Exchange: Schema-Aware Query Transfer

• SQL-Exchange is a structure-preserving framework that maps SQL queries and paired natural-language questions between different database schemas while retaining the original relational logic.
• It employs template-guided transfer and semantic constant substitution to adapt source query structures to target domains, ensuring schema-specific elements are correctly transformed.
• Empirical results demonstrate that SQL-Exchange enhances text-to-SQL performance by providing schema-aligned examples that reduce issues like schema leakage and structural drift.

SQL-Exchange is a framework for mapping an SQL query and its paired natural-language question from one database schema to another while trying to preserve the source query’s logical or structural form and adapt only the schema-specific parts. It is motivated by the observation that many SQL queries across unrelated domains share reusable relational skeletons, yet conventional text-to-SQL and in-context learning pipelines do not systematically transform those skeletons into target-schema examples. SQL-Exchange therefore treats cross-domain query transfer as a distinct problem: given a source question–SQL pair and a target schema, generate a meaningful target question and a target SQL query that preserve the source logic as much as possible while grounding tables, columns, and constants in the target domain (Daviran et al., 9 Aug 2025).

1. Problem statement and conceptual scope

The framework is defined over a source natural-language question $q_s$, a source SQL query $sq_s$, a source schema $s$, and a target schema $t$. Its goal is to generate a target question $q_t$ and a target SQL query $sq_t$ such that $q_t$ is meaningful in the target domain, $sq_t$ correctly expresses $q_t$ over the target schema, and $sq_s$ and $sq_s$0 share the same logical structure while ignoring table names, column names, and constants (Daviran et al., 9 Aug 2025).

This formulation is deliberately narrower than full semantic equivalence and broader than string-level rewriting. The paper uses “equivalence” loosely and makes explicit that the intended notion is structural equivalence rather than semantic equivalence over identical data. A common misconception is therefore to treat SQL-Exchange as a proof-oriented equivalence system; it is instead a structure-preserving transfer framework. This distinction matters because the target schema need not be semantically parallel to the source schema, and the mapping need not preserve exact entities or domain intent. What must transfer is the relational construction: joins, filters, aggregation patterns, grouping, ordering, and nesting.

The motivation is practical. New or niche databases often lack query repositories, while target-domain examples are especially useful for text-to-SQL prompting. The paper notes that prior work cited there reports a 12% gain from target-domain-tailored examples over cross-domain ones. It also identifies query reuse and search, and education or assessment, as additional uses: one can preserve query logic or difficulty while changing the domain, reducing plagiarism and diversifying examples (Daviran et al., 9 Aug 2025).

2. Template-guided transfer and prompt structure

SQL-Exchange takes as input $sq_s$1, $sq_s$2, $sq_s$3, $sq_s$4, sample data from the target schema $sq_s$5, and a demonstration example $sq_s$6 showing a source-to-target mapping from another schema pair. It outputs $sq_s$7 and $sq_s$8 in JSON. The method has two key ideas: template-guided query transfer and constant substitution grounded by target sample data. It is implemented through a structured one-shot prompt with chain-of-thought-style reasoning, and the prompt requires a short thought process, in at most 5 sentences per step (Daviran et al., 9 Aug 2025).

The core mechanism is schema-agnostic abstraction. The source SQL is transformed into a template in which table names, column names, and constants are replaced by placeholders such as table, column, and constant_value. This preserves the structural backbone of the query: SELECT, joins, filters, aggregation, grouping, nesting, and ordering. The prompt explicitly instructs the model first to create tables_columns_replacement, then to generate a new query from that abstraction, then to substitute constants using meaningful values from target sample data, and finally to generate a new natural-language question from the new SQL.

A canonical example in the paper proceeds as follows:

$sq_s$9

is abstracted to:

$s$0

and then grounded in the target schema as:

$s$1

Constants are treated separately because they are often the least portable part of a query. The prompt includes sample rows from relevant target tables and instructs the model to use meaningful values from target schema sample data, not to reuse source constants, and to ensure numerical constants differ from source constants. The paper terms this semantic constant substitution. On BIRD with GPT-4o-mini, zero-shot constant reuse was as high as 72%, and SQL-Exchange reduced this by over 30 percentage points (Daviran et al., 9 Aug 2025).

3. Feasibility, structural preservation, and failure modes

The paper first studies direct zero-shot mapping and identifies two recurring problems. The first is structural drift: the model fails to preserve joins, subqueries, aggregations, or filters, and multi-table logic is flattened into simpler single-table queries. The second is schema leakage: the model copies source table names, column names, or literal values into the target query. One example maps SELECT AVG(Price) FROM playstore WHERE Genres = 'Dating' to SELECT AVG(T1.Price) FROM products AS T1 WHERE T1.Description = 'Dating', thereby copying both Price and 'Dating' into a target schema where they do not fit (Daviran et al., 9 Aug 2025).

SQL-Exchange is feasible when the target schema contains enough relational structure to instantiate the source pattern, at least approximately. The paper describes workable cases such as comparable join paths, aggregation-compatible attributes, suitable filtering columns, and support for nested subqueries or ordering. It also permits limited structural mutation when the target schema requires it. An explicit example replaces a year predicate with STRFTIME('%Y', created) < '2019', which changes the surface realization while remaining structurally faithful enough.

It is equally explicit that mapping is not always possible. A representative failure case uses a target schema, toxicology, with no temporal attributes or event logs, so a source query requiring temporal filtering, aggregation, ordering, and metadata retrieval cannot be instantiated; the model correctly returns null. The paper also notes infeasibility when the source SQL itself is logically invalid, such as malformed HAVING MAX(ibu) AND MIN(ibu). This makes refusal a legitimate output mode rather than a degenerate case (Daviran et al., 9 Aug 2025).

A second misconception follows from these examples: preserving structure is not always synonymous with preserving quality. The paper shows that GPT-4o-mini often preserved structure more aggressively, yet Gemini-1.5-flash produced more executable and semantically aligned outputs. This indicates that exact skeleton preservation can be counterproductive when the target schema requires adaptation.

4. Evaluation methodology and empirical profile

The evaluation uses BIRD and Spider. For each benchmark, source databases are selected from the training set and target databases from the development set. For each source database, up to 20 queries were sampled, except GPT-4o-mini on Spider, where only 10 queries per database were used for cost reasons. Query mapping is evaluated with Gemini-1.5-flash and GPT-4o-mini under long-context settings, and semantic quality is judged by Gemini-2.0-flash, which the paper validates against human annotations (Daviran et al., 9 Aug 2025).

Three primary properties are measured: structural alignment with the source query, execution validity on the target database, and semantic correctness. Semantic correctness is decomposed into NL Meaningfulness and SQL–NL Alignment. The paper also reports Generation Success, and in ablations, Result Yield.

Setting	Structural Alignment	Execution Validity
BIRD, Gemini-1.5-flash	66.59%	89.43%
BIRD, GPT-4o-mini	80.47%	68.33%
SPIDER, Gemini-1.5-flash	82.21%	93.5%
SPIDER, GPT-4o-mini	86.8%	86.29%

These figures are accompanied by high semantic scores for Gemini-1.5-flash: on BIRD, NL Meaningfulness 95.45% and SQL–NL Alignment 82.75%; on SPIDER, 96.41% and 90.02%. GPT-4o-mini shows stronger structural preservation but weaker semantic alignment: 80.03% and 54.57% on BIRD, and 91.78% and 76.13% on SPIDER. Manual evaluation of 144 SQL–NL pairs that passed execution testing reported Meaningful NL and Aligned SQL of 100.0% and 91.1% for BIRD–Gemini, 88.6% and 57.1% for BIRD–GPT, 100.0% and 95.8% for SPIDER–Gemini, and 91.3% and 56.5% for SPIDER–GPT. Gemini-2.0-flash agreed with humans at 94.9% on NL meaningfulness and 85.07% on SQL–NL alignment (Daviran et al., 9 Aug 2025).

The structural edit analysis further clarifies how mappings fail. Deletions dominate overall, with 55.2% of structural edits, versus 32.2% insertions and 12.6% mutations. Most edits occur in JOIN and COND, suggesting that models often simplify structure when schema mismatch is strong. Execution failures are dominated by subtle grounding errors rather than gross structural collapse: Column Reference Errors account for 90.5–93.4% of failures, followed by Syntax Errors at 1.9–6.3%, Table Reference Errors at 0.3–3.2%, Ambiguous Column Names at 0.7–2.5%, and Misuse of Aggregate Functions at 0.2–2.5% (Daviran et al., 9 Aug 2025).

5. SQL-Exchange as in-context example generation for text-to-SQL

The framework’s second major contribution is downstream: mapped target-schema SQL–NL pairs are used as in-context examples for text-to-SQL. The rationale is that an unmapped example from another schema may be structurally relevant but remains schema-incompatible with the target database, which can mislead the model. SQL-Exchange transforms such examples into the target schema while preserving useful logical structure, so the demonstration becomes both structurally relevant and schema-aligned (Daviran et al., 9 Aug 2025).

Example selection uses SQL-Encoder, a 1.3B model trained to estimate structural similarity between SQL queries by comparing their natural-language questions. Retrieved examples come from three pools: source-side unmapped queries, SQL-Exchange mapped outputs, and oracle target-development examples. Downstream models are Llama-3.2-3B-Instruct, Qwen2.5-Coder-3B-Instruct, Qwen2.5-Coder-7B-Instruct, and GPT-4o-mini, evaluated in zero-shot, one-shot, and three-shot settings with execution accuracy.

The dominant empirical pattern is consistent: SQL-Exchange examples outperform unmapped demonstrations, and usually outperform zero-shot as well. On SPIDER with LLaMA-3B, zero-shot is 43.33%, unmapped 1-shot is 43.42%, and SQL-Exchange 1-shot is 57.64%. On BIRD with Qwen-3B, zero-shot is 35.98%, unmapped 1-shot is 31.94%, and SQL-Exchange 1-shot is 41.46%. On SPIDER with GPT-4o-mini, SQL-Exchange 3-shot reaches 73.4% versus 69.44% for unmapped 3-shot. The paper summarizes the gains as up to +8.8% on BIRD and up to +17.2% on SPIDER for smaller models, while even GPT-4o-mini gains +2.7% on BIRD and +6.7% on SPIDER in 3-shot settings (Daviran et al., 9 Aug 2025).

A notable negative result is that unmapped examples often hurt performance, especially in few-shot settings. This directly supports the framework’s central claim: structurally relevant examples written in the wrong schema can be less useful than no example at all. Filtering studies show that semantic filtering matters more than execution filtering for smaller models, whereas stronger models such as GPT-4o-mini are somewhat more robust to imperfect demonstrations.

6. Relation to adjacent research and open problems

SQL-Exchange occupies a specific niche within a broader SQL research landscape. It is not identical to naturally occurring text-to-SQL benchmarking, although that literature provides an important backdrop. SEDE shows that realistic text-to-SQL involves ambiguity, hidden assumptions, procedural SQL, noisy phrasing, and high query diversity, with strong baseline performance dropping sharply relative to Spider (Hazoom et al., 2021). This suggests that schema-aligned mapped examples can improve prompting, but do not remove the broader realism gap exposed by naturally occurring workloads.

It is also distinct from schema-linking and generation pipelines such as SQL-to-Schema, E-SQL, and BASE-SQL. SQL-to-Schema uses an initial SQL query as an intermediate object for schema linking within one database (Yang et al., 2024). E-SQL rewrites the natural-language question into a schema-aware enriched question and adds candidate predicate augmentation (Caferoğlu et al., 2024). BASE-SQL decomposes text-to-SQL into Schema Linking, Candidate SQL Generate, SQL Revision, and SQL Merge Revision (Sheng et al., 15 Feb 2025). SQL-Exchange differs from all three because its target is not SQL generation within a fixed schema but transfer of query structure across schemas.

A second axis of distinction concerns validation. SQL-Exchange is not an SQL equivalence checker. Work on LLM-based equivalence checking shows that semantic equivalence remains difficult, with strong bias toward equivalence predictions on non-equivalent pairs (Singh et al., 2024). Related work also distinguishes semantic equivalence from relaxed equivalence and shows that execution accuracy is often an inadequate proxy for exact interchangeability (Zhao et al., 2023). Qr-Hint, in turn, assumes a wrong SQL query and a correct target query and produces actionable repair hints through stagewise semantic reasoning (Hu et al., 2024). These lines indicate that validating whether a mapped query preserves the intended logic remains a separate and nontrivial problem.

Finally, SQL-Exchange should not be conflated with two other uses of “exchange.” One is dialect adaptation, where ExeSQL uses execution-driven bootstrapping to move text-to-SQL from SQLite toward PostgreSQL, MySQL, and Oracle (Zhang et al., 22 May 2025). The other is database-theoretic data exchange, where “exchange-repairs” and supported-solution semantics address inconsistency and non-positive querying under schema mappings (Cate et al., 2015, Calautti et al., 2023). In SQL-Exchange, by contrast, “exchange” denotes cross-schema transformation of a query and its paired question.

The open problems identified in the paper are therefore structural rather than purely implementation-level. Structural preservation is not always possible. Execution failures are often caused by subtle grounding errors. Strict structure preservation can hurt semantics. The oracle gap remains because mapped examples still underperform true target-schema examples. Few-shot can degrade through context overload or reduced relevance. And the framework has no explicit schema-level verifier. A plausible implication is that future work will combine schema-compatibility estimation, stronger validation, and richer target-side metadata with the current template-guided transfer mechanism.