Enterprises commonly deploy heterogeneous database systems, each of which owns a distinct SQL dialect with different syntax rules, built-in functions, and execution constraints. However, most existing NL2SQL methods assume a single canonical dialect (e.g., SQLite) and struggle to produce queries that are both semantically correct and executable on target engines. Prompt-based approaches tightly couple intent reasoning with dialect syntax, rule-based translators often degrade native operators into generic constructs, and multi-dialect fine-tuning suffers from cross-dialect interference. In this paper, we present Dial, a knowledge-grounded framework for dialect-specific NL2SQL. Dial introduces: (1) a Dialect-Aware Logical Query Planning module that converts natural language into a dialect-aware logical query plan via operator-level intent decomposition and divergence-aware specification; (2) HINT-KB, a hierarchical intent-aware knowledge base that organizes dialect knowledge into i a Canonical Syntax Reference, ii a declarative function repository, and iii a procedural constraint repository; and (3) an execution-driven debugging and semantic verification loop that separates syntactic recovery from logic auditing to prevent semantic drift. We construct DS-NL2SQL, a benchmark covering six major database systems with 2,218 dialect-specific test cases. Experimental results show that Dial consistently improves translation accuracy by 10.25% and dialect feature coverage by 15.77% over state-of-the-art baselines.
Figures & tables
Figure 1. Dialect-Specific NL2SQL Failures.
Figure 2. System Overview of Dial .
Figure 3. Dialect-Specific Error Analysis.
Operator
Semantic Definition
Description Example
Data Sourcing ( Osrc )
Specifies base relations and logical associations, including ANSI joins and dialect-specific correlations such as LATERAL or APPLY .
Source Match and League where Match.league_id = League.id .
Filtering ( Oflt )
Selects tuples using row-level or post-aggregation predicates.
Keep orders after 2020-01-01 and with status = ’completed’
Scalar Calculation ( Ocal )
Computes derived values through row-level transformations, such as casting, string operations, and temporal arithmetic.
Compute amount * 1.08 as amount_with_tax .
Aggregation ( Oagg )
Changes data granularity by grouping records and computing summary metrics.
Group by customer_id and compute AVG(amount) .
Result Organization ( Oorg )
Organizes final results through projection, ordering, and cardinality control.
Sort by avg_amount descending and keep top 10.
Auxiliary Operation ( Oaux )
Captures query-structuring requirements that organize, scope, or combine intermediate logical results, such as CTEs, nested queries, set operations, and window structures.
Use CTEs to compare department and company averages.
Table 1. Standardized Logical Operators in NL-LQP.
Figure 4. Dialect-Aware Logical Query Planning.
Benchmark
Dialect-Specific NL2SQL
Multi-Dialect NL-SQL
Dialectal Incompatibility
Execution Equivalence
# Test Samples
# Dialect Types
# Test Databases
Average Dialectal Discrepancy
Spider ( Yu et al., 2018 )
✗
✗
✗
✗
2,147
1
206
–
BIRD ( Li et al., 2023 )
✗
✗
✗
✗
1,789
1
15
–
BIRD Mini-Dev ( Li et al., 2023 )
✓
✓
✓
✗
500
3
11
1.60
PARROT ( Zhou et al., 2025b )
✗
✗
✓
✓
598
8
–
–
Spider 2.0-Lite ( Lei et al., 2025 )
✓
✗
✗
✗
547
3
158
–
DS-NL2SQL
✓
✓
✓
✓
2,218
6
796
3.67
Table 2. Comparison of our Dialect-Specific NL2SQL Benchmark with other representative benchmarks.
Method
SQLite
PostgreSQL
MySQL
SQL Server
DuckDB
Oracle
Exec
Acc
DFC
Exec
Acc
DFC
Exec
Acc
DFC
Exec
Acc
DFC
Exec
Acc
DFC
Exec
Acc
DFC
Input Prompting
DIN-SQL
83.36
44.27
63.75
69.07
37.83
40.94
49.95
29.13
33.59
73.67
40.08
48.05
65.28
36.93
42.72
66.73
39.13
53.16
Agentar-Scale-SQL
98.69
50.36
74.93
82.10
41.25
44.63
77.95
37.96
48.87
65.24
31.70
37.82
85.75
44.23
54.43
78.58
42.25
50.16
Agentar-Scale-SQL (top-8 upper bound)
99.86
61.90
82.94
91.84
50.45
54.33
86.56
46.26
56.88
74.89
41.07
48.39
94.77
48.30
63.30
92.70
48.76
68.60
Model Finetuning
Table 3. Main performance comparison on DS-NL2SQL across six database dialects. Exec : Executability (%), Acc : Execution Accuracy (%), DFC : Dialect Feature Coverage (%).
Figure 5. Overall Performance Comparison.
Method
Logic Query Planning
HINT-KB
Correction
PostgreSQL
SQL Server
Oracle
Exec
Acc
DFC
Exec
Acc
DFC
Exec
Acc
DFC
Dial
✓
✓
✓
98.33
53.33
78.70
99.00
51.71
85.70
99.21
53.42
76.97
Ablation Variants
1-step NL-LQP
✓
✓
95.52
49.04
68.15
91.48
47.09
69.49
93.72
50.73
66.51
✗
✓
✓
91.64
38.59
53.35
98.16
48.35
69.13
95.16
43.99
52.41
✓
✓
✗
96.98
43.17
58.70
93.21
44.49
61.90
98.35
43.76
51.97
✓
✗
✗
96.53
45.94
61.92
95.63
46.71
61.26
91.34
43.15
48.52
Table 4. Performance Comparison of Dial Variants.
Type
User Question (Abbreviated Intent)
Target Syntax Constraints (Gold)
DIN-SQL
EXESQL
Dialect-SQL
Agentar+SQLGlot
Dial
Target Dialect
U1
List all IP addresses accessed by each city.
LISTAGG(…) (Strictly NO GROUP_CONCAT )
×
×
×
×
✓
Oracle
U2
Find the shipment details matching the ID.
CAST(id AS CHAR) (Strictly NO AS TEXT )
×
✓
✓
×
✓
MySQL
U3
When did the earliest complaint start on 2017-03-22?
TO_DATE(…) (Strictly NO date() function)
×
×
×
×
✓
Oracle
U4
What are the total sales metrics for last month?
Native Numeric (Strictly NO ORM bindings )
✓
✓
×
✓
✓
DuckDB
M1
Combine first, middle, and last names.
first || middle || last (Strictly NO 3-arg CONCAT )
×
×
×
✓
✓
Oracle
M2
Retrieve user details across multiple related logs.
FROM "T1" "T2" (Strictly NO AS keyword)
✓
×
✓
✓
✓
Oracle
Table 5. Dialect-Specific Generation Errors Effectively Resolved by Dial (User questions are abstracted as realistic questions. Target syntax highlights the correct dialect-specific pattern alongside strictly prohibited anti-patterns).
Method
PostgreSQL
SQL Server
Oracle
Exec
Acc
DFC
Exec
Acc
DFC
Exec
Acc
DFC
Dial (Ours)
Qwen-3-Max
98.33
53.33
78.70
99.00
51.71
85.70
99.21
53.42
76.97
DeepSeek-V3.2
96.42
43.10
63.10
99.42
45.39
65.27
98.03
45.77
60.08
GPT-5.2
96.88
48.91
70.95
99.76
51.68
76.84
99.70
48.89
66.64
DIN-SQL
Table 6. Performance over Different LLM Backbones.
Existing text-to-SQL benchmarks are largely centered on SQLite, making it difficult to evaluate whether models can generalize across heterogeneous SQL dialects. However, real-world database systems differ substantially in syntax, functions, type systems, and execution semantics, so the same natural language intent often requires dialect-specific SQL realizations. We introduce UniQL, a human-verified benchmark for cross-dialect text-to-SQL evaluation. UniQL aligns 1,534 natural language questions with executable SQL annotations across 16 SQL dialects, yielding 24,544 dialect-specific queries. All dialects share the same intents, aligned schemas and database contents, enabling controlled evaluation of dialect generalization. UniQL is constructed through a hybrid pipeline combining database migration, SQL translation, execution-guided verification, iterative rule summarization, and human validation. Experiments on both open-source and closed-source LLMs show that current models remain far from dialect-universal, with substantial performance variation across database systems and limited transfer from SQLite success to other dialects. These findings highlight the need for aligned cross-dialect benchmarks and more dialect-aware text-to-SQL methods. Code and data are available at https://github.com/JerryGao818/UniQL
Jianling Gao, Chongyang Tao, Jiayuan Bai +7
1SKLCCSE, Beihang University · 2The University of Hong Kong
Text-to-SQL systems are typically trained and evaluated on a single dialect (SQLite), yet production deployments span PostgreSQL, MySQL, ClickHouse, and beyond. We show that this single-dialect assumption leads to a substantial drop in cross-dialect accuracy for every model we tested. The drop persists across scale, architecture, and even purpose-built text-to-SQL systems. We argue that the fix is to change the generation target: instead of asking an LLM to emit dialect-specific SQL, we have it emit a dialect-agnostic relational algebra query plan, which a deterministic compiler then renders into SQL for any supported backend. Across thirteen models from 3B to frontier scale, this restores cross-dialect portability nearly uniformly, at a small cost in peak accuracy on the model's home dialect for capable prompted models and none once fine-tuned on plans; under matched fine-tuning, plan supervision yields a stronger model than SQL supervision. We also introduce MetricName, a question-aware result-set comparator needed to evaluate fairly across dialects, where existing metrics confound semantic errors with benign cross-dialect variation. More broadly, the result is a reminder that a generation target chosen for execution is not necessarily the one that maximizes generation quality.
Corentin Royer, Robin Oester, Yotam Perlitz +3
IBM Research, Zurich, Switzerland · ETH Zurich, Zurich, Switzerland
SQL dialects vary in syntax, types, and functions across database engines. Text-to-SQL benchmarks, however, predominantly support only SQLite. This creates a critical evaluation gap: cross-dialect evaluation reveals weak per-query agreement (Cohen's ), showing that SQLite performance is an unreliable proxy for other dialects. Yet such evaluation remains prohibitively difficult: existing approaches either require expensive manual query transpilation or rely on tools that often fail on complex SQL. To close this gap, we introduce PolySQL, a novel dual-execution method that eliminates the need for query transpilation by comparing normalized execution results. Notably, our approach achieves higher evaluation fidelity than query transpilation with 100% query coverage. PolySQL comprises three datasets, enabling the first large-scale cross-dialect study. Our study reveals a 10.1% average accuracy drop from SQLite to other dialects and identifies a significant dialect difficulty hierarchy. We find this degradation stems from logical rather than syntactic errors (61% vs. 8%). We release our framework code and leaderboard to enable rigorous dialect-robust evaluation.