---
title: DBMS+LLM Integration in Hybrid Database Systems
url: https://www.emergentmind.com/topics/dbms-llm-integration
type: topic
---

# DBMS+LLM Integration in Hybrid Database Systems

Searching arXiv for recent papers on DBMS+LLM integration to ground the article in current literature.
DBMS+LLM integration denotes a class of system designs in which large language models are embedded into database management system workflows, or DBMS functionality is exposed as a structured substrate for LLM-driven reasoning, retrieval, optimization, and control. The area has evolved from relatively loose “LLM-as-interface” designs toward tightly coupled hybrid architectures in which the DBMS retains responsibility for correctness-critical tasks such as execution, rule enforcement, transactional consistency, or storage management, while the LLM contributes semantic interpretation, plan comparison, hint extraction, diagnosis, or constrained generation [2412.18022]. Recent work frames DBMSs and LLMs as “dual infrastructures” of enterprise systems and identifies multiple architectural patterns—DB-first, LLM-first, middle-layer, pipe-connected, and platform-based—rather than a single canonical integration strategy [2507.19254].

## 1. Architectural patterns and system boundaries

A recurring distinction in the literature is whether the DBMS or the LLM is the primary control locus. The survey on industrial and business applications organizes the design space into five representative patterns: DB-first, LLM-first, middle-layer, pipe-connected, and platform-based [2507.19254]. In DB-first systems, the DBMS remains the central control system and LLM functionality is embedded into components such as the interface layer, optimizer, executor, or UDF/operator layer. In LLM-first systems, the LLM is the main orchestration and reasoning layer, while the DBMS is treated as a supporting backend for retrieval, storage, or SQL execution. Middle-layer systems insert an explicit orchestration layer between DBMS and LLM. Pipe-connected systems couple them through batch or stream pipelines. Platform-based systems rely on a managed cloud platform to coordinate both.

This taxonomy aligns with a broader tutorial perspective that treats integration as bidirectional: “LLMs for DBs” includes DBA support, tuning, text-to-SQL, and query optimization, whereas “DBs for LLMs” includes external memory, retrieval, scheduling, and system support for inference [2412.18022]. A plausible implication is that DBMS+LLM integration is not a single systems problem but a family of co-design problems spanning query processing, memory architecture, control flow, and serving infrastructure.

Several concrete systems exemplify DB-first designs. LLM4Hint is described as a **DBMS+LLM hybrid system for offline query optimization** that recommends hints rather than generating execution plans from scratch [2507.03384]. SQL-invoked LLM query systems study how `llm_complete`, `llm_filter`, and `llm_reduce` fit into relational plans such as `Scan -> Join -> Projection (llm_complete)` or `Scan -> Join -> Filter (llm_filter) -> Projection` [2508.20912]. BlendSQL-style execution treats LLM functions as typed operators inside SQL-like declarative programs, compiling them into ordinary SQL plus temporary tables or scalar values so the final query can be run by the database engine [2509.20208].

Other systems are explicitly hybrid rather than purely DB-first. LLM-R² keeps Apache Calcite’s rule executor as the final authority and uses an LLM only as a rule-suggestion engine [2404.12872]. FuzzySQL uses LLMs selectively inside a grammar-guided fuzzing pipeline, while grammar parsing, mutation rewrites, replay, and minimization remain rule-based [2602.19490]. SysInsight uses static code analysis and LLM reasoning to extract knob-controlled execution paths from DBMS source code, but transforms the resulting hypotheses into verifiable tuning rules through association rule mining and diagnoses bottleneck functions before adjusting knobs [2603.22708]. DBAIOps inserts expert DBA experience into a heterogeneous graph and then uses a reasoning LLM to infer root causes and generate diagnosis reports [2508.01136].

## 2. Query optimization and rewrite integration

Query optimization is one of the most technically developed DBMS+LLM subareas. Two distinct integration strategies appear in the literature. One uses the LLM as a direct plan generator. The other keeps the DBMS optimizer or rewrite engine as the executor and uses the LLM as a ranking, selection, or control layer.

LLM-QO adopts the direct generation strategy. It formulates query optimization in an autoregressive fashion that directly generates the execution plan without explicit plan enumeration [2502.05562]. Its input is serialized by QInstruct, which includes the SQL query, instruction, auxiliary metadata such as per-column statistics in the format **[min, max, distinct count]**, a one-shot planning demonstration, and a target plan serialized as a planning path plus bracket representation. The two-stage training pipeline combines Query Instruction Tuning and Query Direct Preference Optimization, with preference pairs derived from runtime comparisons between plans from multiple optimizers. The system is built on PostgreSQL’s execution engine and uses **pg_hint_plan** to transform the generated representation into an executable PostgreSQL plan [2502.05562].

LLM4Hint represents the ranking strategy. Its central idea is to keep the DBMS in charge of plan enumeration, while using an LLM to compare and rank the candidate plans produced under different hints [2507.03384]. The workflow begins with a SQL query \(q\). A larger commercial LLM \(\mathcal{M}_l\) rewrites the SQL into a more natural-language-like description \(q_c\). For each candidate hint \(h \in H\), PostgreSQL is invoked with `EXPLAIN` to produce a query execution plan \(p_q^h\). A lightweight plan encoder \(\mathcal{M}_p\), built on QueryFormer, produces a **sequence of embeddings** that becomes a soft prompt appended to the backbone LLM \(\mathcal{M}_b\). Together with the rewritten SQL, hint text, and an explicit matching prompt, the backbone LLM outputs a plan embedding, and a comparator \(\mathcal{M}_c\) predicts which of two hinted plans is better. By aggregating pairwise comparison outcomes, the system selects the best hint [2507.03384]. It recommends among **16 hint combinations** selected from the 48 combinations studied in Bao and follows Lero’s pairwise relative comparison setup rather than predicting absolute execution time.

The query rewrite literature adopts a similar “LLM as control layer, DBMS as executor” pattern. LLM-R² avoids asking the LLM to directly synthesize executable SQL. Instead, the LLM sees an instruction \(I\), a rule instruction \(R\) listing all candidate rules with descriptions, a one-shot demonstration \(D=\langle Q^D, R^D\rangle\), and the input query \(Q\), combined as
\[
P = I \oplus R \oplus D \oplus Q,
\]
and predicts a rule sequence
\[
R^* = ICL_M(P),
\]
which is executed by Apache Calcite’s rule rewriter to obtain
\[
Q^* = R^*(Q)
\]
[2404.12872]. This preserves executability and equivalence by construction because the actual transformations are restricted to known rewrite rules. Demonstration selection is optimized through a contrastive selector trained on triplets \(\langle Q^t, Q^{D+}, Q^{D-}\rangle\), with curriculum learning used to stabilize training under limited supervision [2404.12872].

Performance results in this area motivate the hybrid design choice. LLM4Hint reports **SU = 1.70** and **GMRL = 0.79** on **JOB-Q**, **SU = 1.86** and **GMRL = 0.75** on **TPC-DS-Q**, and **SU = 1.16** and **GMRL = 0.90** on **Stack**, and it emphasizes gains in both effectiveness and generalization [2507.03384]. LLM-R² reports average execution time reductions relative to the original of **52.5% on TPC-H, 56.0% on IMDB, and 39.8% on DSB**, while the rewrite-count analysis reports 323/302/341 rewrites on TPC-H/IMDB/DSB with 305/292/222 being improvements [2404.12872]. These systems do not eliminate the DBMS optimizer; they restructure the optimizer’s decision boundary.

A technically important detail across these papers is alignment between LLM token spaces and DBMS-native structure. LLM4Hint explicitly addresses the discrepancy between token sequences and execution plans with rich numerical features by combining a lightweight plan encoder, a soft prompt, query rewriting, and an explicit matching prompt. It reports that absolute matching performs better than relative matching and that rewritten SQL gives clear gains on JOB-Q and TPC-DS-Q, particularly for predicates such as `LIKE` and `IN` [2507.03384]. This suggests that plan-aware prompting, not raw SQL-to-plan generation alone, is a central systems problem.

## 3. LLM operators inside declarative query execution

Another integration line places LLM calls directly inside declarative languages. Here the main issue is not only semantic usefulness but also type correctness, planner interaction, structured output enforcement, batching, and resource utilization.

The BlendSQL work formalizes LLM calls as well-typed functions in SQL-like declarative programs [2509.20208]. It builds on functions such as `llmqa` and `llmmap`, embedded in queries using double-curly-brace syntax, and compiles them into ordinary SQL plus temporary tables or scalar values. The central claim is that generated outputs must satisfy both type constraints imposed by the SQL expression and database-content constraints imposed by actual database values. The paper proposes a decoding-level type alignment algorithm with three steps: infer the function’s return type from expression context, map that type to a regular expression or grammar constraint, and cast the output into the native type before splicing it back into the SQL AST [2509.20208]. Example inference rules include
\[
f() \rightarrow \text{bool}
\]
for `f() = TRUE`,
\[
f() \rightarrow \text{int}
\]
for `f() > 40`,
and
\[
f() \rightarrow \text{Literal}[\{'Washington DC', 'San Jose'\}]
\]
for `city = f()` [2509.20208]. Constrained decoding is implemented with Guidance, and database values are lowercase-normalized to reduce false mismatches.

The execution model is explicitly DB-first. Given query AST \(A\), language model \(L\), database \(D\), and function \(F\), the system gathers referenced tables, materializes CTEs if necessary, executes the LLM function, transforms the AST with the typed result, and returns the rewritten AST [2509.20208]. Native SQL operators are treated as cheap, while LLM functions are treated as expensive, so the rule-based optimizer eagerly evaluates ordinary SQL operators and defers LLM calls. On TAG-Bench, BlendSQL reports about **0.76 s** versus **1.7 s** for LOTUS, a **53% latency reduction**, and on HybridQA the paper highlights a **7% accuracy improvement**, with one cited result being a **6.6-point denotation accuracy increase** after applying type constraints [2509.20208].

A complementary systems study examines SQL-invoked LLM support in PostgreSQL + pgAI, DuckDB + FlockMTL, and MotherDuck [2508.20912]. Using five representative query classes—LLM Projection, LLM Filter, Multi-LLM Invocation, LLM Aggregation, and RAG—it identifies three core challenges: enforcing structured outputs, optimizing resource utilization, and improving query planning. The paper reports that Q2 and Q3 fail on pgAI and FlockMTL with Ollama due to structured output problems, while FlockMTL succeeds only after switching to vLLM with structured decoding. Q4 succeeds only on MotherDuck because FlockMTL still exhibits a planner/type mismatch, and Q5 fails on MotherDuck and FlockMTL due to query planning issues, succeeding on pgAI only after manually forcing a better plan [2508.20912]. Performance numbers illustrate the current maturity gap: `pgAI-Ollama` reports **719.5 minutes** for Q1 and **204.9 minutes** for Q5, `FlockMTL-vLLM` reports **342.4 minutes** for Q1 and **617.2 minutes** for Q3, while `MotherDuck-GPT` reports **16.2 minutes** for Q1, **4.3 minutes** for Q2, and **8.3 minutes** for Q4 [2508.20912].

The structured-output issue appears repeatedly in the broader literature. The tutorial on trustworthy and efficient LLMs highlights constrained decoding as a method for increasing correctness and efficiency by forcing outputs to follow a desired structure [2412.18022]. In the SQL setting, this is not merely formatting convenience: Q2 and Q3 require outputs exactly equal to `"Yes"`, Q4 requires a pure numeric value consumable by `AVG()`, and post-processing repair loops are criticized as too slow for database execution pipelines [2508.20912; 2509.20208].

## 4. External memory, retrieval, and relational augmentation

A separate strand treats the DBMS primarily as an external memory substrate for LLMs. The objective is not to embed semantic operators into SQL, but to give an LLM access to precise, up-to-date, and private information stored in relational databases [2407.15071].

The “Relational Database Augmented Large Language Model” proposes an LLM-agnostic memory architecture with three components: database selection memory, data value memory, and relational databases [2407.15071]. The pipeline begins with a context switch module that asks whether the context of the question already contains the answer. If not, the memory module performs database selection, LLM-based retrieval planning, and value-aware SQL correction. Database selection is implemented as an embedding-based nearest-neighbor retrieval problem over textified schemas, trained using Spider and Dr. Spider. The paper uses **top 5 candidate databases** in experiments [2407.15071].

A key technical point is the distinction between schema awareness and value awareness. The paper argues that text-to-SQL systems often know the schema but not the actual stored values. For example, a question may mention “Los Angeles” while the database stores `LA`. The system therefore builds a column-wise value memory for each database, parses the candidate SQL to identify column-literal pairs, retrieves semantically similar stored values, and prompts the LLM to correct only the string literals in the SQL conditions [2407.15071]. Output generation then decides whether the SQL result should be returned directly or converted into a natural-language answer.

The reported results show that the framework enables database-grounded answering where base LLMs fail. For GPT-3.5 with 5 databases, the paper reports **0.64 / 0.63** SQL / answer accuracy on single-DB questions and **0.60 / 0.37** on double-DB questions; for Claude-2 with 20 databases, it reports **0.66 / 0.54** on single-DB questions and **0.54 / 0.44** on double-DB questions [2407.15071]. Database selection refinement improves precision/recall/F1 from **0.13 / 0.89 / 0.23** to **0.64 / 0.81 / 0.71** with 20 candidate databases, and data value memory improves SQL accuracy by about **0.063** on average and answer accuracy by about **0.038** on average [2407.15071].

This retrieval-oriented architecture differs from DB-first declarative execution. In the former, the LLM orchestrates which databases to consult and how to phrase the answer; in the latter, the DBMS executes a typed plan in which LLM calls appear as operators. The tutorial literature explicitly presents both as valid forms of compound AI systems, but stresses that retrieval itself introduces heterogeneity, scalability, sparsity, and reliability issues [2412.18022]. The survey on industrial integration makes the same point in architectural terms: LLM-first systems are attractive for flexible interaction, but weaker on query correctness, efficiency, and governance than DB-first systems [2507.19254].

## 5. Tuning, administration, and operational intelligence

DBMS+LLM integration is not limited to query execution. A large body of work uses LLMs to incorporate textual DBA knowledge, source-code semantics, runtime evidence, or graph-structured experience into tuning and operational workflows.

GPTuner is a manual-reading database tuning system that converts natural-language guidance from manuals, forums, and GPT into a Tuning Lake and then into Structured Knowledge via a prompt ensemble with majority voting [2311.03157]. It uses this knowledge for workload-aware knob selection, search-space optimization, and a coarse-to-fine Bayesian Optimization framework. The paper reports that GPTuner identifies better configurations in **16× less time on average** and achieves up to **30% performance improvement** over the best-performing alternative [2311.03157]. The tuning objective is formalized as
\[
\boldsymbol{\theta}^{*} = \arg\max_{\boldsymbol{\theta} \in \boldsymbol{\Theta}} f(\boldsymbol{\theta}),
\]
with the search space reduced using attributes such as `suggested_value`, `min_value`, `max_value`, and `special_value` [2311.03157].

DemoTuner places the LLM upstream of reinforcement learning rather than inside the online tuning loop [2511.09998]. It extracts structured hints of the form
\[
\langle knob,\ rec\_action,\ condition\_vector\rangle
\]
from manuals, forums, blogs, and configuration documents using a structured chain-of-thought prompt and GPT-3.5-Turbo [2511.09998]. These hints seed HA-DDPGfD, a hint-aware demonstration reinforcement learning algorithm. The system reports **19** performance-critical knobs and **70 hints** for MySQL, **18** performance-critical knobs and **104 hints** for PostgreSQL, and average best performance gains over default of **44.01%** on MySQL and **39.95%** on PostgreSQL [2511.09998]. It also reports lower online tuning cost than the baselines across the tested workloads.

SysInsight shifts the knowledge source from manuals to source code [2603.22708]. For each target knob \(k\), it uses ConfMapper and static taint analysis over LLVM IR to construct a function–knob mapping, then invokes an AST-based retrieval agent with `search_function(f)` and `search_class(cls)` APIs so that an LLM can reason about knob-controlled execution paths and produce semantic tuning hypotheses [2603.22708]. These hypotheses are converted into quantitative rules using association rule mining, with rules represented as
\[
\left( \bigwedge_{k=1}^{K} p_k(w) \ \land \ \bigwedge_{j=1}^{N} r_j \in [l_j, u_j] \right) \Longrightarrow \left( \bigwedge_{i=1}^{M} \theta_i : [\text{adjustment}] \right).
\]
The system reports convergence to the best configuration **7.11× faster on average** than GPTuner while achieving a **19.9% performance improvement**, extracts hypotheses for **all 44 knobs**, and mines high-confidence tuning rules for **33 knobs** [2603.22708].

Operational diagnosis systems show a different integration pattern. D-Bot treats the LLM as a database administrator that mines maintenance experiences from documents, retrieves tools, performs tree-of-thought reasoning, and supports collaborative diagnosis among multiple agents [2308.05481]. DBAIOps instead materializes expert experience in a heterogeneous graph
\[
\mathcal{G} = (\mathcal{V}, \mathcal{E}, \mathcal{R}),
\]
with Trigger Vertex, Experience Vertex, Tool Vertex, Metric Vertex, Tag Vertex, and Auxiliary Vertex, and combines “800+” reusable anomaly models with a two-stage graph evolution mechanism and a reasoning LLM [2508.01136]. On aggregate diagnosis performance, DBAIOps with DeepSeek-R1 32B reaches **0.92**, and with DeepSeek-R1 671B reaches **0.94**, reported as **61.40%** and **34.29%** better than the corresponding LLM-only performances of **0.57** and **0.70** [2508.01136]. The paper also reports a **34.85%** improvement in root-cause accuracy and **47.22%** in human evaluation accuracy over state-of-the-art baselines [2508.01136].

Across these tuning and O&M systems, the LLM is rarely trusted as an autonomous optimizer or diagnostician. Instead, it is grounded by structured knowledge, runtime feedback, association mining, tool APIs, anomaly models, or knowledge graphs. This suggests that operational DBMS+LLM integration has converged on evidence-constrained reasoning rather than free-form advisory generation.

## 6. Testing, verification, and safety-critical control

Testing and verification papers provide some of the clearest statements about safe integration boundaries. They repeatedly reject unconstrained “generate SQL from scratch” usage in favor of grammar guidance, rule execution, formal proof, replay, or differential testing.

FuzzySQL targets under-tested DBMS special features such as GTID control, `PROCEDURE`, `KILL`, `INSTALL COMPONENT`, and `RESET BINARY LOGS AND GTIDS` [2602.19490]. The pipeline begins with grammar-guided SQL generation from ANTLR4 `.g4` grammars, classifying grammar constructs into `SequenceRule`, `OptionalRule`, `ChoiceRule`, and `RepeatRule`. The LLM instantiates these templates under schema context, and the resulting tests are evolved using **Algorithm 1: Logic-Shifting Progressive Mutation**, with inputs `\mathcal{T}_1`, `\mathcal{T}_2`, schema sets `\mathcal{S}_1`, `\mathcal{S}_2`, operation sequences `\mathcal{O}_1`, `\mathcal{O}_2`, and a drop probability sampled as `p_{\text{drop} \sim \mathcal{U}(0.2, 0.4)` [2602.19490]. When SQL fails, a hybrid repair pipeline applies syntax-aware filtering, rule-based repair, and finally LLM-based semantic repair. Across MySQL, MariaDB, SQLite, PostgreSQL, and ClickHouse, the paper reports **37 distinct bugs**, **29 confirmed**, **9 assigned CVE identifiers**, **14 already fixed**, and **7 feature-related** [2602.19490].

Argus addresses a different bottleneck: automated discovery of test oracles for DBMS testing [2510.06663]. Its central abstraction is the Constrained Abstract Query pair,
\[
(\mathsf{Schema}^{\dagger},\ \mathsf{CAQ},\ \mathsf{CAQ}),
\]
where each CAQ is a SQL skeleton plus placeholder map. The LLM generates candidate equivalent CAQ pairs, but soundness is enforced by SQLSolver, which formally proves equivalence before any oracle is used [2510.06663]. After verification, Argus instantiates placeholders using reusable snippet corpora generated by LLMs and grammar-based methods, subject to determinism, null-preserving, and empty-preserving constraints. The framework reports **40 previously unknown bugs**, **35 logic bugs**, **36 confirmed**, and **26 already fixed** across Dolt, DuckDB, MySQL, PostgreSQL, and TiDB [2510.06663]. An ablation replacing the prover with GPT-based judgment yields overwhelmingly false positives, underscoring the importance of formal verification [2510.06663].

Connector testing exhibits the same pattern. The reinforcement-learning-guided connector testing framework uses parameterized prompt templates plus UCB1 prompt selection to generate JDBC tests and differential testing across multiple connectors [2506.11870]. It reports **16 total issues**, including **7 bugs in MySQL Connector/J**, **3 bugs in OceanBase Connector/J**, and **6 unsafe implementations in OceanBase Connector/J**, with **10 issues officially confirmed** [2506.11870]. The reward signal is the number of observed behavioral discrepancies, and the UCB-based selector chooses prompts according to
\[
\mu_i + \sqrt{\frac{2\log R}{s_i}}.
\]
MIST, in contrast, targets DBMS SQL test generation using documentation-aware prompting and Monte Carlo Tree Search [2603.21530]. It reports average improvements of **43.3% in line coverage**, **32.3% in function coverage**, and **46.4% in branch coverage** compared to the baseline, with the highest line coverage of **69.3% in the Optimizer module** [2603.21530].

Safety-critical control appears in transaction management as well. “A Simple and Fast Way to Handle Semantic Errors in Transactions” treats LLM-generated transactions as potentially semantically incorrect and proposes middleware based on Invariant Satisfaction, an adaptation of invariant confluence [2412.12493]. Suspicious or compensating transactions are buffered, a dependency matrix records which later transactions would make them unrecoverable, and new transactions are held until review when they are not I-satisfied with buffered ones. The paper frames the trade-off as a “CAD theorem” involving consistency, availability, and dependency, and evaluates buffered rate under varying suspicious-transaction frequency, review frequency, and invariant completeness [2412.12493]. This is not an optimization or retrieval use case; it is an explicit attempt to preserve the “C” in ACID under LLM-generated actions.

## 7. Recurring design principles, trade-offs, and open problems

Across these systems, several common principles recur. First, successful designs almost never replace the DBMS’s correctness-critical core. LLM4Hint does not replace plan enumeration; it selects hints for the DBMS [2507.03384]. LLM-R² does not rewrite SQL directly; it predicts rule sequences executed by Apache Calcite [2404.12872]. FuzzySQL does not use the LLM as an unconstrained SQL generator; grammar and repair stages impose structure [2602.19490]. Argus does not trust LLM-generated oracles without proof [2510.06663]. SysInsight does not treat LLM reasoning as self-validating; hypotheses are transformed into verifiable rules via association mining [2603.22708].

Second, alignment between symbolic structure and language-model interfaces is a central bottleneck. Examples include soft prompts over plan embeddings and explicit matching prompts in LLM4Hint [2507.03384], expression-context-based type inference and constrained decoding in BlendSQL [2509.20208], value memories for literal correction in relational database augmented LLMs [2407.15071], and graph-constrained diagnosis prompts in DBAIOps [2508.01136]. The tutorial literature frames this more generally as the need for compound AI systems rather than prompt-only solutions [2412.18022].

Third, output structure is not ancillary. It is a systems requirement. SQL-invoked LLM queries require exact `"Yes"`/`"No"` outputs or numeric values consumable by aggregates [2508.20912]. Declarative LLM functions need type-correct and database-aligned outputs [2509.20208]. Testing systems need formally valid equivalence or replayable failure cases [2510.06663; 2602.19490]. O&M systems need diagnosis reports grounded in graph paths and anomaly evidence rather than generic prose [2508.01136]. This is why constrained decoding, grammar guidance, rule execution, and typed AST integration appear so often.

Fourth, many systems accept additional cost only in offline or high-value settings. LLM4Hint is explicitly designed for **offline optimization of recurring queries** and not online per-query optimization [2507.03384]. SysInsight shifts substantial cost offline, reporting about **45 hours** for function–knob extraction and about **4 hours / \$5** for LLM-based hypothesis generation, with online recommendation taking about **26 seconds** per next-configuration suggestion [2603.22708]. GPTuner treats knowledge extraction cost as reusable, reporting **880,000 tokens** and **\$29.5** to prepare PostgreSQL knowledge [2311.03157]. Such cost placement reflects a broader systems judgment: LLM reasoning is tolerable when amortized, but still too expensive for many tight control loops.

The survey literature identifies major unresolved issues. For DB-first architectures, these include cross-model query execution, cost modeling for non-deterministic and variable-latency LLM operators, and cross-modal operator design [2507.19254]. For LLM-first systems, limited declarativity, fragile tool use, and weaker control over correctness remain central problems [2507.19254]. The tutorial literature adds open questions around mixed relational–LLM workload optimization, lack of accurate cost models for batch time and memory use, and the absence of widely accepted benchmarks for relational-LLM workloads [2412.18022].

A recurring misconception is that DBMS+LLM integration is equivalent to text-to-SQL or to attaching an external API call to a database. The literature is more specific. Integration may involve hint recommendation, rule-sequence prediction, typed UDF execution, code-driven knob analysis, graph-evolved diagnosis, grammar-guided fuzzing, oracle synthesis with formal proof, or invariant-aware transaction middleware. Another misconception is that stronger general-purpose models alone solve the problem. Multiple papers instead show that structure dominates: moderate-sized backbones plus rewriting and matching can outperform stronger but poorly aligned models in offline optimization [2507.03384]; smaller executors can approach larger baselines when constrained by query context [2509.20208]; local models can outperform frontier models on coverage growth when embedded in a semantics-aware fuzzing pipeline [2602.19490].

Taken together, the literature portrays DBMS+LLM integration as a field of constrained hybridization. The DBMS supplies plan generation, execution, runtime measurements, storage, transactions, rules, or graph/query infrastructure. The LLM supplies semantic abstraction, comparison, control, translation, or evidence synthesis. The dominant research trajectory is not substitution of one for the other, but the design of interfaces precise enough that language-model reasoning can operate without violating database semantics, type rules, safety properties, or operational constraints [2412.18022; 2507.19254].

Source: https://www.emergentmind.com/topics/dbms-llm-integration