DBMS+LLM Integration in Hybrid Database Systems

• DBMS+LLM integration is a hybrid approach that embeds large language models into database workflows to enhance planning, optimization, and semantic interpretation.
• Architectural patterns span from DB-first to LLM-first strategies, balancing strict control of integrity with LLM-driven hint generation and rule application.
• Key applications include adaptive query rewriting, type-aware LLM functions, and operational tuning that leverage structured outputs and constrained decoding.

Searching arXiv for papers on DBMS+LLM integration to ground the article in current literature. DBMS+LLM integration denotes a class of system designs in which LLMs 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 (Kim et al., 2024). 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 (Yan et al., 25 Jul 2025).

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 (Yan et al., 25 Jul 2025). 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 (Kim et al., 2024). 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 (Liu et al., 4 Jul 2025). SQL-invoked LLM query systems study how llm_complete, llm_filter, and llm_reduce fit into relational plans such as Scan -> Join -> [Projection](https://www.emergentmind.com/topics/predictive-head-projection) (llm_complete) or Scan -> Join -> Filter (llm_filter) -> Projection (Akillioglu et al., 28 Aug 2025). 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 (Glenn et al., 24 Sep 2025).

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 (Li et al., 2024). FuzzySQL uses LLMs selectively inside a grammar-guided fuzzing pipeline, while grammar parsing, mutation rewrites, replay, and minimization remain rule-based (Chen et al., 23 Feb 2026). 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 (Zhang et al., 24 Mar 2026). DBAIOps inserts expert DBA experience into a heterogeneous graph and then uses a reasoning LLM to infer root causes and generate diagnosis reports (Zhou et al., 2 Aug 2025).

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 (Tan et al., 8 Feb 2025). 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 (Tan et al., 8 Feb 2025).

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 (Liu et al., 4 Jul 2025). 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 (Liu et al., 4 Jul 2025). 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 $\mathcal{M}_l$0, and the input query $\mathcal{M}_l$1, combined as

$\mathcal{M}_l$2

and predicts a rule sequence

$\mathcal{M}_l$3

which is executed by Apache Calcite’s rule rewriter to obtain

$\mathcal{M}_l$4

(Li et al., 2024). 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 $\mathcal{M}_l$5, with curriculum learning used to stabilize training under limited supervision (Li et al., 2024).

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 (Liu et al., 4 Jul 2025). 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 (Li et al., 2024). 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 (Liu et al., 4 Jul 2025). 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 (Glenn et al., 24 Sep 2025). 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 (Glenn et al., 24 Sep 2025). Example inference rules include

$\mathcal{M}_l$6

for f() = TRUE,

$\mathcal{M}_l$7

for f() > 40, and

$\mathcal{M}_l$8

for city = f() (Glenn et al., 24 Sep 2025). 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 $\mathcal{M}_l$9, LLM $q_c$0, database $q_c$1, and function $q_c$2, 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 (Glenn et al., 24 Sep 2025). 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 (Glenn et al., 24 Sep 2025).

A complementary systems study examines SQL-invoked LLM support in PostgreSQL + pgAI, DuckDB + FlockMTL, and MotherDuck (Akillioglu et al., 28 Aug 2025). 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 (Akillioglu et al., 28 Aug 2025). 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 (Akillioglu et al., 28 Aug 2025).

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 (Kim et al., 2024). 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 (Akillioglu et al., 28 Aug 2025, Glenn et al., 24 Sep 2025).

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 (Qin et al., 2024).

The “Relational Database Augmented LLM” proposes an LLM-agnostic memory architecture with three components: database selection memory, data value memory, and relational databases (Qin et al., 2024). 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 (Qin et al., 2024).

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 (Qin et al., 2024). 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 (Qin et al., 2024). 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 (Qin et al., 2024).

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 (Kim et al., 2024). 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 (Yan et al., 25 Jul 2025).

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 (Lao et al., 2023). 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 (Lao et al., 2023). The tuning objective is formalized as

$q_c$3

with the search space reduced using attributes such as suggested_value, min_value, max_value, and special_value (Lao et al., 2023).

DemoTuner places the LLM upstream of reinforcement learning rather than inside the online tuning loop (Dou et al., 13 Nov 2025). It extracts structured hints of the form

$q_c$4

from manuals, forums, blogs, and configuration documents using a structured chain-of-thought prompt and GPT-3.5-Turbo (Dou et al., 13 Nov 2025). 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 (Dou et al., 13 Nov 2025). It also reports lower online tuning cost than the baselines across the tested workloads.

SysInsight shifts the knowledge source from manuals to source code (Zhang et al., 24 Mar 2026). For each target knob $q_c$5, 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 (Zhang et al., 24 Mar 2026). These hypotheses are converted into quantitative rules using association rule mining, with rules represented as

$q_c$6

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 (Zhang et al., 24 Mar 2026).

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 (Zhou et al., 2023). DBAIOps instead materializes expert experience in a heterogeneous graph

$q_c$7

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 (Zhou et al., 2 Aug 2025). 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 (Zhou et al., 2 Aug 2025). 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 (Zhou et al., 2 Aug 2025).

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 (Chen et al., 23 Feb 2026). 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) (Chen et al., 23 Feb 2026). 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 (Chen et al., 23 Feb 2026).

Argus addresses a different bottleneck: automated discovery of test oracles for DBMS testing (Mang et al., 8 Oct 2025). Its central abstraction is the Constrained Abstract Query pair,

$q_c$8

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 (Mang et al., 8 Oct 2025). 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 (Mang et al., 8 Oct 2025). An ablation replacing the prover with GPT-based judgment yields overwhelmingly false positives, underscoring the importance of formal verification (Mang et al., 8 Oct 2025).

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 (Lyu et al., 13 Jun 2025). 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 (Lyu et al., 13 Jun 2025). The reward signal is the number of observed behavioral discrepancies, and the UCB-based selector chooses prompts according to

$q_c$9

MIST, in contrast, targets DBMS SQL test generation using documentation-aware prompting and Monte Carlo Tree Search (Chen et al., 23 Mar 2026). 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 (Chen et al., 23 Mar 2026).

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 (Zeng et al., 2024). 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 (Zeng et al., 2024). 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 (Liu et al., 4 Jul 2025). LLM-R² does not rewrite SQL directly; it predicts rule sequences executed by Apache Calcite (Li et al., 2024). FuzzySQL does not use the LLM as an unconstrained SQL generator; grammar and repair stages impose structure (Chen et al., 23 Feb 2026). Argus does not trust LLM-generated oracles without proof (Mang et al., 8 Oct 2025). SysInsight does not treat LLM reasoning as self-validating; hypotheses are transformed into verifiable rules via association mining (Zhang et al., 24 Mar 2026).

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 (Liu et al., 4 Jul 2025), expression-context-based type inference and constrained decoding in BlendSQL (Glenn et al., 24 Sep 2025), value memories for literal correction in relational database augmented LLMs (Qin et al., 2024), and graph-constrained diagnosis prompts in DBAIOps (Zhou et al., 2 Aug 2025). The tutorial literature frames this more generally as the need for compound AI systems rather than prompt-only solutions (Kim et al., 2024).

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 (Akillioglu et al., 28 Aug 2025). Declarative LLM functions need type-correct and database-aligned outputs (Glenn et al., 24 Sep 2025). Testing systems need formally valid equivalence or replayable failure cases (Mang et al., 8 Oct 2025, Chen et al., 23 Feb 2026). O&M systems need diagnosis reports grounded in graph paths and anomaly evidence rather than generic prose (Zhou et al., 2 Aug 2025). 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 (Liu et al., 4 Jul 2025). SysInsight shifts substantial cost offline, reporting about 45 hours for function–knob extraction and about 4 hours / \$h \in H$029.5 to prepare PostgreSQL knowledge (Lao et al., 2023). 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 (Yan et al., 25 Jul 2025). For LLM-first systems, limited declarativity, fragile tool use, and weaker control over correctness remain central problems (Yan et al., 25 Jul 2025). 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 (Kim et al., 2024).

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 (Liu et al., 4 Jul 2025); smaller executors can approach larger baselines when constrained by query context (Glenn et al., 24 Sep 2025); local models can outperform frontier models on coverage growth when embedded in a semantics-aware fuzzing pipeline (Chen et al., 23 Feb 2026).

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 (Kim et al., 2024, Yan et al., 25 Jul 2025).