SQLGovernor: LLM-Powered SQL Toolkit

• SQLGovernor is an LLM-powered SQL toolkit that unifies syntax correction, query rewriting, modification, and equivalence verification for complex OLAP queries.
• It employs a fragment-wise processing strategy to decompose long, nested queries into manageable parts, ensuring focused analysis and coherent recombination.
• A hybrid self-learning mechanism driven by expert feedback and historical data yields measurable improvements in query execution efficiency and accuracy.

SQLGovernor is an LLM-powered SQL toolkit for real world analytical environments. It is designed as a middleware layer between SQL producers and the DBMS, and unifies syntax correction, query rewriting, query modification, and consistency verification within a structured framework enhanced by knowledge management. Its defining technical features are a fragment wise processing strategy for long and deeply nested OLAP queries and a hybrid self learning mechanism guided by expert feedback, with reported gains on benchmarks such as BIRD and BIRD CRITIC, as well as industrial datasets (Jiang et al., 10 Sep 2025).

1. Problem domain and conceptual scope

SQLGovernor targets production analytical SQL rather than short transactional statements. The motivating setting is complex OLAP, where queries are long, deeply nested, and may use CTEs, subqueries, window functions, and complex joins; where data volumes are large; and where queries are often scheduled or repeated for dashboards and reports. In this regime, SQL quality directly affects compute cost, SLAs, and decision quality. The paper identifies three recurring problem classes: syntax errors, inefficiency, and semantic misalignment or inconsistency (Jiang et al., 10 Sep 2025).

Syntax errors include invalid SQL that cannot execute, such as missing keywords, wrong join conditions, column count mismatches, invalid function usage, and dialect mismatches. Inefficiency refers to semantically correct SQL that is unnecessarily slow or resource hungry, including redundant scans, suboptimal joins, overly broad SELECT and WHERE clauses, and unnecessary nesting or window functions. Semantic misalignment denotes cases where SQL is syntactically correct and may run efficiently, but does not match user intent, uses the wrong grouping or time window, or diverges from a golden reference query. For text-to-SQL pipelines, the paper states that this last category is the dominant failure mode (Jiang et al., 10 Sep 2025).

The paper frames these issues against three systemic deficits in existing practice. First, the tool ecosystem is fragmented: SQLFixAgent and Self-Debugging focus on error correction, WeTune, LLM-R², GenRewrite, and LimeQO focus on rewriting or optimization, and FuncEvalGMN focuses on equivalence verification. Second, many methods are not OLAP-tailored and degrade on long, nested queries or large schemas. Third, the knowledge lifecycle remains expert-centric, making rule maintenance expensive as schemas and workloads evolve. SQLGovernor is proposed specifically to consolidate these functions and to reduce the manual integration burden that otherwise incurs 30–40% extra manual effort and 25–35% higher labor cost in expert-centric workflows (Jiang et al., 10 Sep 2025).

The industrial motivation is explicit in the Payment-SQL dataset described in the paper: queries average 421 tokens, all qualify as “Hard” in Spider 2.0’s terms, and the schema contains 74 tables with thousands of columns. SQLGovernor is therefore not a general natural-language interface alone; it is a governance layer for high-complexity SQL production paths (Jiang et al., 10 Sep 2025).

2. System architecture and fragment-wise processing

At system level, SQLGovernor is a middleware toolkit that sits between SQL producers and the DBMS. It exposes four specialized tools—Syntax Error Corrector, Query Rewriter, Query Modifier, and Equivalence Verifier—supported by a central Knowledge Management module. Inputs may be raw SQL, SQL plus a natural-language modification request, or SQL pairs for equivalence checking. Outputs may be corrected SQL, rewritten SQL, modified SQL, or an equivalence judgment, with execution feedback routed back into the knowledge loop (Jiang et al., 10 Sep 2025).

A central architectural decision is fragment wise processing. SQLGovernor recursively partitions a query into the main query, CTE bodies, and nested subqueries, then processes each fragment independently before recombination. The paper formalizes this with a recursive algorithm: divide_CTE(Q) separates CTE definitions from the main query; parse_subqueries(Q_main) extracts nested subqueries; and fragment_processing(fragment) is applied recursively to each component, producing a set of fragment-level analysis results. This decomposition is intended to reduce prompt length, mitigate lost-in-the-middle effects, and concentrate LLM reasoning on the local structure where an error or inefficiency actually occurs (Jiang et al., 10 Sep 2025).

Fragment-wise processing is not merely a prompt compression device. It is also the mechanism by which rule matching becomes fine grained. A fragment can be a CTE body, a subquery in SELECT, FROM, or WHERE, or the outer query stripped of embedded subqueries. Each fragment is analyzed with only the local context and schema subset needed for the current tool. The paper states that this yields shorter prompts, more focused context, and better rule application, while recombination preserves structure except where changes are intentional (Jiang et al., 10 Sep 2025).

The recombination stage imposes a strong coherence requirement. Rewritten or corrected fragments must remain syntactically valid and semantically equivalent to the original fragment where the task requires preservation, while global coherence must maintain aliases, CTE names, references, join keys, correlated subqueries, and projection alignment. The system addresses this by passing enough local context into each prompt, avoiding cross-fragment structural changes unless explicitly planned, and using equivalence checks or regression-like tests where possible. A plausible implication is that SQLGovernor treats SQL transformation as a structured program transformation problem rather than a single end-to-end sequence generation task (Jiang et al., 10 Sep 2025).

3. Core toolchain

The toolkit is organized around four named tools with distinct operational goals (Jiang et al., 10 Sep 2025).

Tool	Primary task	Core mechanism
Syntax Error Corrector	Fix syntactic errors	DBMS log analysis, rule retrieval, localized correction
Query Rewriter	Produce semantically equivalent but more efficient SQL	Fragment evaluation, rule-guided rewriting, historical examples
Query Modifier	Modify SQL from natural-language requests	Intent classification, metadata preparation, task-specific prompting
Equivalence Verifier	Judge whether two SELECT-based SQL queries are semantically equivalent	Semantic intent extraction, pre-filtering, hierarchical consistency checking

The Syntax Error Corrector follows a three-stage workflow. In clarification, it extracts exception type, error location, and error message from DBMS logs using regular expressions. These normalized error phrases are used to retrieve entries from the syntax-correction rules store, where each entry specifies whether schema information is needed, whether the error is localizable or global, and what fixing guidance applies. In data preparation, the system chooses the relevant schema subset and the fragment scope. In correction, it prompts the LLM with the erroneous fragment or full SQL, extracted error information, selected schema snippet, and any retrieved fixing rule, instructing the model to fix syntax while preserving intent as much as possible (Jiang et al., 10 Sep 2025).

The Query Rewriter is a two-stage pipeline. In evaluation, each fragment first undergoes rule-based pre-checking by template extraction and rule matching. If inefficiency rules match, a Scenario 1 prompt asks the LLM to determine which rules are actually applicable and to translate them into actionable transformations. If no inefficiency rule matches and the fragment is not already covered by an “already efficient SQL” rule, a Scenario 2 prompt asks the LLM to analyze the query intent and propose more efficient formulations while preserving semantics. In rewriting, SQLGovernor retrieves similar historical rewriting examples from the knowledge base and uses them together with the fragment and suggested transformations to generate a rewritten fragment (Jiang et al., 10 Sep 2025).

The paper’s worked example illustrates two specific rule labels. LEFT_JOIN_IS_NOT_NULL captures the case where a LEFT JOIN is followed by WHERE right.col IS NOT NULL, which is logically an INNER JOIN. SAME_TABLE_JOIN captures repeated scans of the same table in separate subqueries. The reported rewrite introduces a CTE that scans tb0 once and replaces LEFT JOIN plus WHERE tb2.ds IS NOT NULL with INNER JOIN tb2, preserving final semantics while reducing IO and join overhead (Jiang et al., 10 Sep 2025).

The Query Modifier supports four intent categories: realizing specific semantics, explaining SQL, adopting specified syntax or style, and other SQL-related tasks. Its routing mechanism combines keyword matching and embedding-based semantic scoring. For category $C_j$, the keyword score is

$$S_j^{kw} = \frac{1}{N_j} \sum_{k_{ji} \in \mathcal{KW}_j} \mathrm{match}(\mathcal{Q}, k_{ji}) \times w_{ji},$$

and the final decision score is

$$F_j = \alpha \cdot S_j^{kw} + \beta \cdot \text{similarity}(\mathbf{e}_\mathcal{Q}, \mathbf{e}_{\mathcal{C}_j}).$$

The paper reports that an instruction-aware Qwen3 embedding achieved 78.9% accuracy for intent classification with 0.173s latency, whereas Qwen3-32B achieved 84.3% accuracy but 0.354s latency; the embedding-based route is preferred in latency-sensitive settings (Jiang et al., 10 Sep 2025).

The Equivalence Verifier is restricted to SELECT-based DML. It first translates each query into a structured natural-language semantic description, capturing SELECT fields, source tables, operations, filters, joins, and grouping, parsed inside-out from nested subqueries to the outer query. It then applies a pre-filter to reject obviously non-equivalent pairs, such as those with different numbers of SELECT fields or incompatible grouping shapes. Finally, hierarchical consistency checking asks the LLM to align fields bidirectionally, reason over semantic equivalence, and consider counterexamples to reduce positive bias (Jiang et al., 10 Sep 2025).

4. Knowledge management and hybrid self-learning

Knowledge Management is the persistent substrate that differentiates SQLGovernor from isolated LLM prompting. Each tool has a dedicated knowledge base partitioned into a Rules module and a Historical Data module. For the Query Rewriter, rules are stored as entries such as <index, description>, where the index is a label like SAME_TABLE_JOIN and the description encodes pattern, rationale, and recommended transformation. For the Syntax Error Corrector, the rules store <exception pattern, fixing action> pairs derived from documentation and FAQs. Historical Data stores high-quality cases from real usage as <index, details, tag>, where the tag links a case to the corresponding rule family (Jiang et al., 10 Sep 2025).

The storage backend is heterogeneous by design. Historical Data is embedded and stored in a vector database based on StarRocks, with SQL templates formed by masking table and column names. Retrieval is top-$k$ nearest-neighbor search with cosine similarity, followed by filtering using the tag field. Rule storage depends on tool characteristics: Query Rewriter rules are indexed in ElasticSearch for fast exact or keyword matching, whereas Syntax Error Corrector rules are stored in a vector DB because detailed error messages vary across DBMS versions and require approximate matching (Jiang et al., 10 Sep 2025).

The self-learning mechanism is hybrid in two senses. First, initialization is partly expert-curated: experts provide initial rewriting rules to complement DBMS optimizers, and syntax rules are distilled from FAQs and documentation. Second, runtime logs drive continuous expansion. When queries fail or are inefficient, SQLGovernor filters the logs for relevant features such as error messages, query structure, and execution time, then uses an LLM rule-generation prompt to synthesize generalizable rules expressed as JSON with pattern keys and detailed descriptions. The resulting proposals are not inserted automatically; they are subjected to threshold-triggered expert review (Jiang et al., 10 Sep 2025).

The review mechanism uses two triggers: $$t_1 = \left\lfloor \lambda \cdot \sqrt{N_{\text{current}}} \right\rfloor,\qquad t_2 = \beta \cdot \mathbb{E}[\Delta t_{\text{historical}}],$$ with $\lambda = 2.5$ and $\beta = 1.3$. Verification is triggered when the number of new rules exceeds $t_1$, or when time since the last update exceeds $t_2$. To suppress redundancy, rule descriptions are embedded with RoBERTa into $\mathbb{R}^{768}$, pairwise cosine similarity is computed, and DBSCAN clusters similar rules. The retained cluster representative is

$$S_j^{kw} = \frac{1}{N_j} \sum_{k_{ji} \in \mathcal{KW}_j} \mathrm{match}(\mathcal{Q}, k_{ji}) \times w_{ji},$$0

Validated rules are then added to the knowledge base, and successful applications are recorded back into Historical Data. The paper characterizes this process as enabling the system to “evolve with every step” (Jiang et al., 10 Sep 2025).

5. Empirical performance, deployment profile, and limitations

SQLGovernor is evaluated on BIRD, BIRD-CRITIC (Flash), and the industrial Payment-SQL dataset. On BIRD dev, it is used as a post-processing layer over fine-tuned text-to-SQL models. For CodeS-7B, execution accuracy rises from 57.17 to 64.02 and VES from 58.80 to 64.72. For CodeS-15B, execution accuracy rises from 58.48 to 65.32 and VES from 59.87 to 67.87. For XiYan-32B, execution accuracy rises from 67.01 to 68.97 and VES from 67.79 to 70.89. The paper also reports that gains are larger on more complex query categories than on simple ones (Jiang et al., 10 Sep 2025).

On BIRD-CRITIC-Flash, SQLGovernor improves issue-resolution success rates for general-purpose LLMs. For Qwen3-32B, total success rate increases from 26.0% to 36.0%, with especially large gains in Management and Efficiency. For Qwen2.5-72B-Instruct, total success rate increases from 32.0% to 40.5%. The runtime overhead per query roughly doubles: Qwen3-32B increases from 8.5s to 18.4s, and Qwen2.5-72B-Instruct from 9.8s to 21.3s. The paper characterizes this overhead as acceptable for the corresponding gains (Jiang et al., 10 Sep 2025).

The strongest industrial result is on Payment-SQL, where rewriting is measured by execution time savings. The metrics are

$$S_j^{kw} = \frac{1}{N_j} \sum_{k_{ji} \in \mathcal{KW}_j} \mathrm{match}(\mathcal{Q}, k_{ji}) \times w_{ji},$$1

SQLGovernor achieves ETOG = 45.92%, ETS = 83.86s, and Rewriting Cost = 30.73s, yielding a net gain of +53.13s per query. The paper contrasts this with Qwen3, Qwen2.5, LLM-R², and GenRewrite, each of which achieves lower net gain (Jiang et al., 10 Sep 2025).

The other tool-specific results are more moderate. On erroneous BIRD outputs produced by CodeS-7B and CodeS-15B, syntax correction reaches 25.8% and 25.2% execution accuracy respectively. The Equivalence Verifier reaches 78.9% overall accuracy and 79.3% F1 on CodeS-7B predictions versus ground truth, with lower performance on challenging queries. In a productivity A/B test with 60 practitioners, the integrated framework completes tasks 33% faster overall than manually orchestrated discrete modules, with a 41% gain for non-experts and 25% for experts; the manually orchestrated setup incurs about 18% overhead for tool switching and context reconstruction (Jiang et al., 10 Sep 2025).

The paper is explicit about scope limits. SQLGovernor is designed primarily for standard SQL and specific DBMS settings such as PostgreSQL and in-house OLAP environments, so dialect variation may require adaptation. The Equivalence Verifier is limited to SELECT-based DML; transactions, updates, and side effects are out of scope. Even with selective schema inclusion, extremely complex schemas can still pressure context budgets. More broadly, SQLGovernor is best suited to heavy OLAP workloads, decision support, NL2SQL outputs, and problematic queries identified via monitoring, rather than low-latency OLTP paths (Jiang et al., 10 Sep 2025).

6. Broader governor lineage and adjacent systems

The term “governor” has a broader technical lineage in control. In control theory, a governor is a supervisory layer that modifies the commands sent to a pre-existing controller so that plant constraints are never violated; it sits between the desired command and the controller and acts as a command filter. This description comes from Reference Governor work in input-constrained MPC, where the governor computes a modified reference $$S_j^{kw} = \frac{1}{N_j} \sum_{k_{ji} \in \mathcal{KW}_j} \mathrm{match}(\mathcal{Q}, k_{ji}) \times w_{ji},$$2, predicts future behavior, and accepts or holds the command depending on whether constraints remain satisfied (Fernandez et al., 2022). This suggests a structural analogy to SQLGovernor’s placement between SQL producers and the DBMS, although the control-theoretic and database settings are distinct.

Within text-to-SQL, a related “governor” idea appears in execution-guided selection. “Query and Conquer” describes a model-agnostic layer that sits on top of any text-to-SQL model, generates multiple SQL candidates, executes them or inspects their plans, computes an execution-based similarity matrix, and selects the candidate most consistent with the others under an MBR objective. The paper presents this as a way to expose executability, similarity scores, and outlier detection, and reports that smaller models can surpass heavier reasoning models while reducing inference cost by as much as 30 times (Borchmann et al., 31 Mar 2025). SQLGovernor differs in scope, because it unifies correction, rewriting, modification, and equivalence verification, but both systems place governance logic above the base SQL generator.

A different extension appears in compliance-oriented evaluation. ScenarioBench describes an imagined SQLGovernor-like system as one in which every decision is backed by canonical SQL, clause IDs, and an ordered execution trace that can be checked against policies. It defines strict grounding, no-peek rules, result-set equivalence on clause_id, hallucination scoring, and a Scenario Difficulty Index for jointly evaluating decisions, traces, retrieval, and latency in compliance contexts (Atf et al., 29 Sep 2025). This suggests a trace-grounded interpretation of SQL governance in regulated environments, where the query itself becomes part of an auditable evidence trail.

At the plan-governance level, GALO provides a non-LLM precedent. It acts as a third-tier of re-optimization, after query rewrite and cost-based optimization, learning recurring problem patterns in query execution plans offline and applying guideline-based rewrites online through an RDF and SPARQL knowledge base. The paper explicitly characterizes GALO as a control layer over SQL workloads, specialized on plan-quality governance, with experimental improvements on synthetic TPC-DS and real IBM client workloads (Damasio et al., 2019). SQLGovernor operates at SQL level rather than plan-guideline level, but both systems externalize governance knowledge and apply it between the application and the native optimizer.

A still broader database-copilot perspective is provided by GaussMaster, an LLM-based system for GaussDB that integrates hybrid retrieval, diagnosis trees, 25 DBMind tools, a chief DBA agent plus expert agents, and safety mechanisms for anomaly diagnosis and service repair. It reports zero human intervention for over 34 database maintenance scenarios in banking environments (Zhou et al., 29 Jun 2025). Compared with that architecture, SQLGovernor is narrower and more SQL-centric. It does not attempt comprehensive anomaly diagnosis or full database lifecycle orchestration; instead, it concentrates on SQL transformation and verification. A common misconception is therefore to equate SQLGovernor with an autonomous database platform. The evidence in the paper supports a more specific characterization: it is a middleware SQL governance toolkit that complements, rather than replaces, DBMS optimizers and broader operational copilots (Jiang et al., 10 Sep 2025).