DBA-Bench: A Production-Fidelity Benchmark for LLM-Based Database Operations Agents Junming Chen
Junyang Jiang
Xu Chen
University of Electronic Science and Technology of China Chengdu, China [email protected]
University of Electronic Science and Technology of China Chengdu, China [email protected]
University of Electronic Science and Technology of China Chengdu, China [email protected]
Zibo Liang
Kai Zheng
University of Electronic Science and Technology of China Chengdu, China [email protected]
University of Electronic Science and Technology of China Chengdu, China [email protected]
arXiv:2607.22165v1 [cs.DB] 24 Jul 2026
Abstract LLM-based database agents show promise, but differing task scopes, testbeds, and metrics hinder comparison. We identify four gaps between evaluation and production operations: live-environment fidelity (multi-turn read–write interaction with a running database); observation-space scale and complexity (causal diagnosis across thousands of time series, business logs, and concurrent activity); solutionspace openness (multiple remediations with different operational trade-offs); and scenario complexity and coverage (faults cascading across internal mechanisms and operational domains). We present DBA-Bench, a benchmark addressing these gaps through production fidelity, outcome-first evaluation, and controlled scenario reproducibility. It uses instrumented PostgreSQL environments with active workloads, persistent state, and multi-source observations; defines success by measurable recovery or fault elimination under safety constraints; and restores snapshots with scenario-specific checks before each run. The benchmark contains 106 scenarios across seven task domains, with two public difficulty labels based on reference-path diagnostic depth and environmental complexity. We evaluate nine baseline groups, including six foundation-model systems, two GPT-5.5-backed database agents, and a Human DBA reference. Across 848 automated runs, Diagnosis, Outcome, and Safe Pass rates are 32.7%, 19.6%, and 12.4%; the best automated baseline reaches 17.9% Safe Pass versus 93.4% for the Human DBA reference. Automated Safe Pass falls from 19.6% on Easy scenarios to 7.6% on Hard scenarios, underscoring the difficulty of safe end-to-end remediation.
CCS Concepts • Information systems → Database management system engines; • Computing methodologies → Intelligent agents.
Keywords database operations, LLM agents, benchmark, fault diagnosis
1
Introduction
Database operations span tasks such as query tuning, failure recovery, and schema changes. They unfold on live databases under
concurrent workloads, where interventions change the environment and symptom-level fixes may leave the root cause intact; in a stale-statistics and lock-contention incident, terminating the visible blocker clears the waits only temporarily. Such work is expertiseintensive, continuous, and high-risk, yet experienced database administrators (DBAs) are scarce; LLM-based autonomous agents have therefore been explored as a force-multiplier [16, 28]. A growing number of LLM-based database agents have emerged to address this need—D-Bot [40], DBAIOps [38], DBAgent [5], and report-style advisors such as Panda [28] and GaussMaster [37]— each reporting encouraging results on its respective evaluation setup. These systems pursue different operational goals, and their evaluations consequently use different task scopes, testbeds, metrics, and fault scenarios. To our knowledge, there is no shared, reproducible evaluation environment on which different database agents can be compared under controlled fault conditions. Reported numbers are therefore difficult to compare directly, limiting fieldlevel measurement of progress toward production readiness. The problem is therefore not merely the absence of a common leaderboard. A meaningful benchmark must preserve the operational conditions relevant to how an agent observes, acts, and verifies recovery, and it must judge the agent by the database state its actions produce. Existing evaluations diverge from these requirements along four dimensions. Gap 1: Live-environment fidelity. Database operations are stateful interactions with a running, writable system, not static input–output tasks. Workloads continue while an agent diagnoses a fault, and each probe or remediation—from terminating a session to changing a configuration or running maintenance—can alter locks, optimizer state, availability, and the evidence visible in the next turn. Many database-agent evaluations emphasize diagnostic or recommendation quality: the environment may be represented as a task state, while proposed fixes are estimated, reported, or routed to human approval rather than executed and verified in the environment [5, 28, 38, 40]. Such setups do not jointly measure whether an agent can safely change live database state, adapt to the consequences of its actions, and verify recovery. Gap 2: Observation-space scale and complexity. A production incident is not isolated from the rest of the system. A DBA must localize causal evidence among thousands of metric time-series,
dense business logs, query plans, lock and session activity, background tasks, and signals created by concurrent workloads. General agent benchmarks instead often instantiate fresh, clean databases or compact task environments in which unrelated activity and plausible competing signals are largely absent. Such environments can test task execution in isolation, but they remove the environmental complexity that makes production diagnosis difficult. An agent evaluated under low-noise conditions need not distinguish a causal fault from correlated workload activity or a salient but misleading symptom. Gap 3: Open solution space. Real-world remediation rarely has a single correct answer; competing fixes differ not in correctness but in operational trade-offs. Consider adding a missing index to a busy table: a DBA may use CREATE INDEX during a maintenance window, which completes faster but blocks writes, or CREATE INDEX CONCURRENTLY, which keeps writes available but takes longer and may leave an invalid index if interrupted. Both create the required access path; which is appropriate depends on availability and maintenance constraints. Several database-agent evaluations stop at a recommended answer rather than executing candidate repairs and inspecting the resulting system state [28, 38, 40]. Scoring against a prescribed answer or action cannot recognize alternative valid paths or compare their operational risks. Gap 4: Scenario complexity and coverage. Production database faults are both diverse and compound. A realistic escalation chain—stale statistics causing suboptimal query plans, which amplify lock contention, which exhaust the connection pool—requires an agent to trace causality through multiple layers of database internals before arriving at the true root cause. Treating the surface symptom (connection exhaustion) while ignoring the upstream trigger (stale statistics) is a failed diagnosis regardless of whether the immediate symptom is temporarily relieved. AIOpsLab [9] provides a closely related precedent by evaluating detection, localization, root-cause analysis, and mitigation in interactive microservice environments. Database operations introduce a complementary evaluation scope requiring reasoning over query plans, locks, statistics, storage, and configuration. A benchmark for this setting must also span query tuning, system-fault recovery, routine health maintenance, business-driven schema changes, resource governance, composite faults, and misleading alerts. Together, these gaps require a benchmark with live read–write interaction, a large and noisy operational environment, outcomegrounded support for open solutions, and diverse causal structures. Fair comparison additionally requires every agent to encounter an equivalent causal fault and operational context while preserving the runtime variation of a live system. We present DBA-Bench, a benchmark framework built around three design principles that collectively address these gaps. Production Fidelity means that DBA-Bench provides near-productiongrade fault environments spanning a rich set of complex database scenarios. It instantiates these scenarios within fully instrumented PostgreSQL environments while OLTP, OLAP, or mixed business workloads remain active during diagnosis and verification. These environments preserve internal database state (data distribution, statistics, WAL position, and dead tuples) and expose a broad multisource observation surface, including metrics, system and business logs, query records, and plans—directly addressing Gaps 1, 2, and 4.
Outcome-First Evaluation defines success as measurable performance recovery or fault elimination under the scenario’s operational safety constraints. It credits remediation paths that satisfy the scenario-specific success contract and separately penalizes unsupported, unscoped, or destructive actions—directly addressing Gap 3. Controlled Scenario Reproducibility restores the complete dirty environment after each run and admits the next run only after scenario-specific predicates verify the intended causal state and visible symptoms. This engineering control gives agents equivalent fault conditions while retaining the runtime variation of a live database. Guided by these principles, DBA-Bench instantiates 106 scenarios spanning 7 operational task domains and two public difficulty labels. The labels are derived from two independently annotated attributes: reference-path diagnostic depth, which counts the evidence-grounded causal hops in a DBA-validated reference diagnostic path, and environmental complexity, which quantifies the noise within the tools required by that path. Agents interact with live database environments through a unified tool interface for metric queries, SQL execution, and instance management, mirroring the workflow of a human DBA using monitoring dashboards, SQL terminals, and database management consoles. Each benchmark run forms a closed operational loop: the agent localizes evidence in a live faulty environment, applies remediation, and verifies the outcome while the workload remains active. We evaluate six foundation models under a common ReAct workflow, two GPT-5.5-backed database agents, and a Human DBA reference. Across 848 automated runs, Diagnosis Pass, Outcome Pass, and Safe Pass are 32.7%, 19.6%, and 12.4%, respectively. The best automated Safe Pass rate is 17.9%, versus 93.4% for the Human DBA reference, a 75.5-percentage-point gap. Automated Safe Pass falls from 19.6% on Easy scenarios to 7.6% on Hard scenarios. In summary, this paper makes the following contributions: • DBA-Bench Framework. We design and implement a benchmark for database operations agents that combines live, instrumented database environments with controlled scenario reproduction. The framework covers 106 PostgreSQL scenarios across 7 operational task domains and two difficulty labels derived from separate diagnostic-depth and environmental complexity annotations. It combines active business workloads, a unified tool interface, and declarative scenario orchestration. • Outcome-First Evaluation Protocol. We propose an outcomefirst evaluation methodology in which success requires measurable system recovery without violating operational safety constraints. Scenario-specific outcome verifiers judge the postrun state and structured submission, while separate trace rules assess operational safety. This separation allows different remediation paths to receive credit when they satisfy the same scenario-specific success contract, without conflating recovery with execution safety. • Systematic Empirical Study. We report a comparative evaluation of six foundation-model systems, two database-agent systems, and a Human DBA reference in controlled PostgreSQL environments that preserve these operational properties. The results expose gaps among diagnosis, realized outcomes, and safe remediation, together with capability differences across scenario attributes. 2
Benchmark artifacts are available at https://github.com/TanJI-C/ DBA-Bench.
2
be turned into reproducible agent evaluations; its microservice system boundary, however, leaves database-internal semantics and the safety of database state changes outside the contract. DBABench adapts this operational pattern to plans, locks, statistics, storage, and configuration, while adding post-fix state verification and explicit operational-safety judgments. DBA-Bench builds on these precedents by combining the following requirements in a database-operations instrument: agents must execute fixes, the framework verifies post-fix state, every action is scored for operational safety, different remediation paths can receive credit when they satisfy the same scenario-specific success contract, and each scenario is restored and revalidated against its fault-manifestation predicates before each run.
Related Work
Database automation has long combined specialized diagnosis with policy-specific control. Earlier database diagnosis and autonomousdatabase systems established methods for performance predicates, online anomaly diagnosis, root-cause SQL localization, workloadaware causal analysis, telemetry-based slow-query diagnosis, multimodal root-cause ranking, and policy-specific tuning [19, 20, 23, 24, 26, 30, 34, 39]. These systems provide important diagnostic and control building blocks, but each is centered on a bounded diagnosis or optimization objective [4, 6–8, 18]. Large language models broaden this line of work toward more flexible operational reasoning. LLM-based database-operation systems now span interactive agents, single-pass advisors, and tuning or copilot systems [3, 5, 10, 16, 28, 37, 38, 40]. Adjacent LLM-based incident-management systems recommend root causes and mitigations [1], assist cloud-service monitoring [35], recommend incident queries [14], or perform tool-augmented autonomous root-cause analysis [31]. Together, these systems show that LLMs can support operational reasoning across database and cloud settings, from evidence gathering and diagnosis to remediation advice and tool use. Evaluation has not kept pace with this broader agent scope. Existing studies are tailored to different goals and therefore use different task scopes, testbeds, metrics, and fault scenarios; several emphasize diagnosis or recommendation quality, and some retain human approval before remediation. Collectively, they leave the field without a shared evaluation contract for a general-purpose LLM agent for database operations that reasons over a live database, selects and executes an open-ended remediation, verifies the postfix state, and accounts for operational safety. This gap also makes the reported numbers difficult to compare directly across systems. Benchmark work in other domains offers useful design precedents for this gap. AgentBench evaluates LLMs as agents across multiple interactive environments, making tool-mediated interaction and task success explicit evaluation targets [21]; GAIA extends this view to general-assistant tasks [25]. SWE-bench instead grounds evaluation in real software work: an agent receives a repository snapshot and an issue, edits the codebase, and is judged by the repository’s execution tests [15]. OpsEval complements these settings by measuring IT-operations knowledge [22]. Other benchmarks similarly standardize long-horizon web interaction, execution feedback, and executable software environments [13, 32, 36]. Together, these efforts establish interaction- and outcome-based evaluation contracts, but their state spaces and success criteria are not those of a live database with causal faults and operational risk. Database-focused benchmarks remain narrower: DBPA and ADBench evaluate transactional performance anomalies or anomaly detectors over curated data [11, 12]. AIOpsLab is the closest operational precedent. It deploys microservice environments, injects fine-grained faults, generates workloads and telemetry, exposes a common agent–cloud interface, and evaluates agents across detection, localization, root-cause analysis, and mitigation [9]. This framework demonstrates how realistic, interactive incidents can
3 DBA-Bench 3.1 Problem Definition Database operations are stateful decision-making tasks rather than single-turn question-answering tasks. An agent receives an initial symptom, alternates reasoning with tool-mediated observation and intervention, and terminates with a report after its actions may have changed the database environment. We define a scenario as 𝑠 = (𝑑𝑠 , 𝑤𝑠 , 𝑓𝑠 , 𝜎𝑠 , U𝑠 , J𝑠 ), where 𝑑𝑠 specifies the database and deployment, 𝑤𝑠 the active workload, 𝑓𝑠 the fault program, and 𝜎𝑠 the initial symptom presented to the agent. U𝑠 is the tool catalog exposed in the scenario, and J𝑠 is its evaluator, which keeps the outcome verifier 𝑉𝑠 , rule-based diagnosis matcher, and trace-based safety rules as separate components. Scenario construction materializes 𝑠 as a restored dirty environment 𝐸𝑠0 . We use 𝐸𝑠𝑡 to denote the complete live database environment at turn 𝑡, encompassing its database and runtime state, active workload, and observable telemetry. For agent 𝑎, a complete run is recorded as 𝑛 𝜏𝑠𝑎 = 𝜎𝑠 , (𝑧𝑖 )𝑖=1 , 𝑟𝑠𝑎 , 𝑛 is the time-ordered sequence of interaction events and where (𝑧𝑖 )𝑖=1 𝑟𝑠𝑎 is the terminal report. An event may record an agent-emitted reasoning or control state, a tool call, an observation, or an architecturespecific tree or graph update. This event representation accommodates sequential, tree-structured, and graph-structured control. For example, a ReAct run instantiates the trace as 𝑎 −1 𝑎 𝜏𝑠,ReAct = 𝜎𝑠 , (𝑞𝑡 , 𝑢𝑡 , 𝑜𝑡 +1 )𝑇𝑡 =0 , 𝑟𝑠 ,
where 𝑞𝑡 , 𝑢𝑡 , and 𝑜𝑡 +1 are respectively the Think record, tool action, and returned observation, and 𝑇 is the number of ReAct interaction turns. The structured report 𝑟𝑠𝑎 records the root-cause type, affected objects, causal factors, supporting evidence, executed actions, and verification evidence. Scoring uses these structured fields; an optional narrative explanation remains in the trace for analysis. The final environment is denoted by 𝐸𝑠𝑎 . The scenario evaluator J𝑠 consumes the trace and post-fix environment and returns a multi-dimensional evaluation record: 𝑅𝑠 (𝑎) = J𝑠 (𝐸𝑠𝑎 , 𝜏𝑠𝑎 ). Section 3.3 details how the trace is produced, and Section 5 defines the evaluation dimensions. 3
Scenario Construction DB System Stack
Workload Stack
Agent-environment Interaction Query Plan Join
OLTP OLAP
…… ……
Environment
Multi-dimensional Evaluation
Knowledge base
Time-series Metrics (CPU, Memory, Disk, …)
Query tuning
System failure
Dirty Environment Instance Generation
Health check
Evaluator Accuracy
…… …… ……
DB Instances
System/DB Log
Agent Submission
Fault Scenarios
Post-fix Environment
Multi-dimensional Hybrid Evaluation
Tool Set execute SQL
metrics
search knowledge
Agent Report & Traces
read log
manage instances
Outcome
Pass / Fail
Multi-turn: Action & Observation
Performance
Agent Stack
Fault Solved
Business Resource Composite Misleading change governance faults alerts
7 categories 106 scenarios · 2 difficulty levels
Safety
Efficiency
Verified
Figure 1: DBA-Bench architecture for 106 PostgreSQL scenarios, from scenario construction through stateful agent– environment interaction to outcome-first, multi-dimensional evaluation. Figure 1 summarizes how DBA-Bench evaluates this problem as a stateful workflow: a database stack, workload, and fault program instantiate a dirty environment; an agent interacts with that environment through a unified tool boundary; and the evaluator judges the post-fix state together with the agent’s trace and report. The key design requirement is that every agent starts from an equivalently manifested dirty state, acts through the same operational interface, and is judged by the same outcome-oriented protocol. We describe the three stages in the order shown in the figure.
3.2
high level, each fault program declares its preconditions, activation procedure, manifestation predicates, and post-fix verifier. The generator deploys the database and data, starts and warms up 𝑤𝑠 , executes 𝑓𝑠 , and waits until the causal state and intended symptom satisfy the manifestation predicates. It then prepares the metrics and logs visible to the agent and captures the complete dirty state. The scenario is admitted only after the declared fault manifests. The resulting evidence remains distributed across the database and telemetry. Before each agent run, DBA-Bench restores the complete dirty environment from a snapshot of database, workload, and deployment state, then reruns the scenario-specific manifestation predicates. A run begins only if the intended causal state and visible symptoms are present. After the run, the environment is discarded and reconstructed for the next agent. This protocol reproduces the scenario-level fault conditions without requiring identical runtime schedules, observations, or agent trajectories. Executable fault programs and post-activation admission checks build on the broader systems-testing practice of injecting faults under explicit consistency constraints [2] and validating controller behavior against automatically constructed failure scenarios [29].
Scenario Construction: From Configurations to Dirty Environments
The first stage turns the declarative scenario 𝑠 into a fault reproduced on an actual database system. The resulting task is a live fault: 𝑓𝑠 is executed against the database and materialized in optimizer state, locks, logs, metrics, storage behavior, workload response, or configuration state. The database specification 𝑑𝑠 determines the deployed engine, data, schema, resources, and initial configuration. The workload specification 𝑤𝑠 selects an OLTP, OLAP, or mixed workload regime. OLTP workloads reproduce high-concurrency short transactions and their lock and connection pressure; OLAP workloads exercise long scans, joins, temporary data, and sustained resource use; mixed workloads expose interference between the two. DBA-Bench scenarios thereby cover database internals such as plans, statistics, vacuum behavior, lock state, WAL/checkpoint pressure, and local configuration. The selected workload remains active during diagnosis and verification, so the agent reasons about a running database under load. The scenario library spans seven operational task domains: query tuning, system failure, periodic health check, business change, resource governance, composite faults, and misleading alerts. Section 4 develops this taxonomy and its difficulty annotations. At a
3.3
Agent–environment Interaction: Stateful Multi-turn Diagnosis and Remediation
The second stage executes the interaction recorded by 𝜏𝑠𝑎 . Starting from 𝜎𝑠 and 𝐸𝑠0 , the agent repeatedly emits a reasoning or control state, invokes a tool, and incorporates the returned observation. The loop ends with the Report action or when the run budget is reached; until then, tool calls may reveal evidence or change the environment on which later decisions depend. 3.3.1 Agent Families and Integration Boundary. DBA-Bench accepts agent architectures with different internal control structures 4
through a common integration boundary. ReAct agents use a Think–Act–Observe loop: they reason over accumulated observations, select the next tool call, and revise their hypothesis from the returned evidence [5, 33]. Tree-search agents, represented by DBot, maintain a tree over hypothesis–action candidates and select diagnostic paths using node scoring or UCT-style exploration [40]. Knowledge-graph-guided agents, represented by DBAIOps, organize evidence and diagnostic experience as graph-structured entities and relations, then use the graph to constrain reasoning and report generation [38]. 𝑛 differThese architectures organize the internal events (𝑧𝑖 )𝑖=1 ently. The common interface provides each architecture with 𝜎𝑠 and U𝑠 , initializes the environment at 𝐸𝑠0 , and records the resulting trace 𝜏𝑠𝑎 and report 𝑟𝑠𝑎 under a shared submission schema. Only actions actually issued through U𝑠 can change the environment and enter outcome verification; advisory or hypothetical recommendations remain trace records.
turns, tool calls, wall-clock time, or tokens, but these are measurement constraints rather than solution hints. On termination, the agent emits the structured report 𝑟𝑠𝑎 . 3.3.3 Operational Knowledge. Operational knowledge is exposed as part of the environment rather than embedded in prompts as scenario-specific hints. Agents access it through the knowledgebase API. The underlying corpus consists of database manuals, operational runbooks, troubleshooting guides, tuning documents, metric and log references, and de-identified incident notes when available. It excludes scenario labels, verifier predicates, gold root causes, and gold remediations. These source classes follow database assistants that ground diagnosis in manuals, troubleshooting material, telemetry, and historical tickets [3, 5, 40]. DBA-Bench can expose the same corpus through three representations. A flat document view supports lexical or vector retrieval over cleaned chunks with document identifiers, section paths, system tags, and entity metadata, following retrieval-augmented grounding used by database advisors [3, 17, 28]. A hierarchical view organizes documents into sections, chunks, diagnostic procedures, metrics, and actions, matching the layered organization explored by DBAgent and D-Bot [5, 40]. D-Bot’s summary-tree chunks with name, content, metrics, and steps are one such representation. A knowledge-graph view materializes symptoms, metrics, log patterns, root causes, database objects, configuration knobs, operations, risks, and verification signals, with relations such as indicates, causes, mitigates, requires-evidence, and unsafe-under, following the graph-structured experience model in DBAIOps [38]. Agent-specific adapters may consume chunks, hierarchical procedures, or graph triples, but all representations derive from the same source corpus and expose no hidden ground truth.
3.3.2 Tool Interface and Protocol. The scenario tool catalog introduced in Section 3.1 is U𝑠 = {𝑢 metric, 𝑢 sql, 𝑢 instance, 𝑢 log, 𝑢 kb }. Each action in the trace has the form 𝑢𝑡 = 𝑢 (𝜃 𝑡 ), where 𝑢 ∈ U𝑠 and 𝜃 𝑡 contains its arguments. Executing the action while the workload remains active advances the live environment: 𝑢𝑡
𝐸𝑠𝑡 −−−→ 𝐸𝑠𝑡 +1, and returns observation 𝑜𝑡 +1 . An observational call does not directly mutate database state, but 𝐸𝑠𝑡 +1 may still differ from 𝐸𝑠𝑡 because the active workload and background processes continue to evolve. The five elements of U𝑠 correspond directly to the benchmark APIs. query_metrics queries database and system monitoring time series, including workload and query-level signals. execute_sql executes an arbitrary SQL query or command, covering catalog inspection, live session and lock state, EXPLAIN-based plan analysis, and SQL-expressible remediation. manage_instance provides process control and configuration management. read_log reads system or database logs, and query_knowledge_base retrieves the local official-documentation corpus. The first, fourth, and fifth APIs are observational; execute_sql and manage_instance can also change state. execute_sql is intentionally expressive. Database engines expose a large fraction of diagnosis and remediation through SQL, so this single API plays the role that a shell tool plays in terminaloriented benchmarks: it provides a compositional command surface instead of restricting agents to a fixed menu of prewritten probes and repairs. This freedom includes powerful DDL, DML, maintenance, and session-control operations. The evaluator J𝑠 judges their safety from the recorded trace under the scenario-specific operational constraints. The environment exposes the broad evidence surface a DBA would consult during an incident: query plans, time-series metrics, system and database logs, slow-query records, operational knowledge, and live database state. These signals are deliberately broader than the minimal evidence needed for the answer; the benchmark measures whether the agent can localize the relevant signal inside a noisy operational surface. Every call, argument, observation, and state-changing result is recorded in 𝜏𝑠𝑎 . Run budgets may bound
3.4
Evaluation Interface: Post-fix State, Report, and Trace
The final stage applies J𝑠 to the post-fix environment 𝐸𝑠𝑎 , structured report 𝑟𝑠𝑎 , and complete trace 𝜏𝑠𝑎 . The outcome verifier 𝑉𝑠 checks the post-run state and the task-specific fields of the submission; the diagnosis matcher scores normalized root-cause fields; and the safety rules inspect the action trace. The evaluator returns the multidimensional record 𝑅𝑠 (𝑎) while keeping these judgments separate. Section 5 details the evaluation protocol.
4
Scenario Taxonomy
DBA-Bench’s scenario taxonomy covers the operational surface of database maintenance. It defines the task domains that a general database operations agent should handle, from routine performance tuning to compound incident response, and characterizes each scenario using two measurable attributes: diagnostic depth and environmental complexity. Reporting these attributes separately identifies whether a failure is associated with a longer causal chain, a noisier evidence space, or their combination.
4.1
Coverage Across Operational Task Domains
Candidate scenarios are collected from documented operational cases in public issue reports and postmortems, official troubleshooting material and runbooks, prior database-diagnosis studies and 5
benchmarks, and expert-designed stress cases. Anonymized production incidents are recorded as a separate provenance class when available. Each scenario retains its source type and a traceable reference or abstraction note. Candidate cases are deduplicated, assigned to an operational domain, and screened for implementability, observable fault manifestation, and automatic outcome verification. DBAs then review the causal fault, reference diagnostic path, operational constraints, and verifier. A scenario enters the benchmark library only after disagreements are resolved and repeated construction satisfies its manifestation predicates. We organize the resulting library around top-level task domains, allowing each domain to contain different diagnostic and remediation paths. For example, query-tuning scenarios may require different actions depending on the workload, schema, and dirty state. The seven categories follow a consistent assignment rule. A scenario is classified as a composite fault when successful resolution requires reasoning about multiple causal faults. Among the remaining scenarios, misleading alerts are those whose dominant initial symptom supports a plausible non-causal explanation. All other scenarios are classified by their primary operational objective: improving query performance, recovering service availability, identifying latent risks, executing a planned business change, or enforcing resource and policy requirements. This rule keeps the category stable when similar database operations appear in different operational contexts. Table 1 summarizes the top-level task domains and reports the Easy/Hard split within each domain. The first five task domains cover common operational duties, from incident response to preventive checks and governed state changes. The final two intentionally stress compound and misleading cases, where the benchmark must distinguish root-cause remediation from symptom chasing.
4.2
Time-series Metrics
DB system tables
Signal mixed with worload effects
Shallow Scan 1
Sees Blocker
2
Stops holder
3
Fault returns
Diagnos tic depth
Failed Path
pg_locks pg_stat_activity Causal sessions buried among background activity
Business logs
Routine entries: dominate Relevant event: order-api timeout High business-noise concentration
visible alert Write timeouts + lock waits
Deep Scan
queue and 4 Lock service symptoms
3 checkout workers update session row 1 They wait behind order-api Write requests time out
3 Slow lock-owning statement
order-api first updates session row 1 then scans customer 42 orders The row lock is held for the full statement
2 Cardinality underestimation
Planner uses stale 300K-row statistics Hot-key rows are severely underestimated The unexpectedly large scan prolongs the statement Evidence tag: estimate ≪ actual
1 hidden root cause Post-ANALYZE distribution shift Statistics captured 300K baseline rows Then +1.2M rows were inserted Actual table size: 1.5M rows autovacuum disabled statistics remain stale
Map the lock chain
1
pg_locks
Inspect the holder state
2
pg_stat_activity
Compare plan estimates
3
EXPLAIN ANALYZE
4
Inspect table statistics
n_mod_since_analyze
5
Solution ANALYZE order_event;
Successful Path
Figure 2: A representative PostgreSQL scenario with diagnostic depth 𝐷𝑠 = 4 and environmental complexity 𝐶𝑠 > 0.9. The successful path follows four logical hops from the visible symptom to stale statistics. units. We define the aggregate signal ratio and environmental complexity as Í 𝑢 ∈ K𝑠 𝑚𝑠,𝑢 𝜌𝑠 = Í , 𝐶𝑠 = 1 − 𝜌 𝑠 . 𝑢 ∈ K𝑠 (𝑚𝑠,𝑢 + 𝑛𝑠,𝑢 ) Units are log lines for log results, rows for tabular results, and data points inside or outside the causal window for time series. Because these tools expose unfiltered results from the same live workload, path-level noise also serves as a proxy for broader noncausal activity in the environment. Isolated query-tuning scenarios usually expose no competing observations; unless such signals are present, they have 𝑛𝑠,𝑢 = 0 and 𝐶𝑠 = 0. We set the complexity boundary to 𝐶 0 = 0.5 and label 𝐶𝑠 < 𝐶 0 as Low complexity and 𝐶𝑠 ≥ 𝐶 0 as High complexity. Difficulty is defined directly from the two independent attributes: ( Hard, 𝐷𝑠 > 𝐷 0 ∧ 𝐶𝑠 ≥ 𝐶 0, Difficulty(𝑠) = Easy, otherwise.
Reference-Path Diagnostic Depth and Environmental Complexity
Diagnostic depth. Each scenario defines a DBA-validated reference diagnostic path 𝜋𝑠 = ⟨𝜎𝑠 , ℎ 1, . . . , ℎ𝐷𝑠 −1, 𝑐𝑠 ⟩,
Environment Complexity
Relevant pattern: p95 ↑, throughput ↓ sessions ↑
𝐷𝑠 = |𝜋𝑠 | − 1,
where 𝜎𝑠 is the initial symptom, ℎ𝑖 is an intermediate diagnostic state, and 𝑐𝑠 is the root-cause state, which may contain multiple causal faults in a composite scenario. Each adjacent pair in 𝜋𝑠 contributes one logical hop and must be supported by observable evidence. Reference-path diagnostic depth 𝐷𝑠 is the number of logical hops in this path. Because the path is not claimed to be unique or shortest, 𝐷𝑠 is a reproducible scenario annotation rather than an intrinsic minimum. Alternative valid paths receive the same outcome credit, and agent turns, repeated tool calls, remediation, and verification do not affect 𝐷𝑠 . We set the low-depth boundary to 𝐷 0 = 2. Environmental complexity. This attribute measures the noise returned by the tools needed to follow 𝜋𝑠 . Let K𝑠 be those key diagnostic tools. Under the reference-path queries, 𝑚𝑠,𝑢 counts returned units that support the causal path and 𝑛𝑠,𝑢 counts the remaining
The 106-scenario library contains 42 Easy and 64 Hard scenarios. The numeric values 𝐷𝑠 and 𝐶𝑠 remain in the benchmark metadata and are analyzed separately in Section 6, preserving the distinct sources of difficulty in comparisons across task categories and agent families.
4.3
Representative Complex Scenario
Figure 2 makes the two difficulty attributes concrete. After statistics are collected on a 300K-row baseline, 1.2M rows for a hot key are inserted while autovacuum is disabled. The planner therefore underestimates the matching rows and chooses a plan whose large 6
Table 1: DBA-Bench scenario taxonomy by operational task domain and aggregate Easy/Hard label derived from diagnostic depth and environmental complexity. The table covers all 106 PostgreSQL scenarios. Category Query tuning System failure Periodic health check Business change Resource governance Composite faults Misleading alerts
Representative operational focus Plan regressions, missing/ineffective indexes, stale statistics Unavailability, lock contention, checkpoint/log pressure, degraded recovery Latent storage, vacuum, statistics, configuration, replication Schema evolution, index/config updates, data migration Capacity pressure, quotas, unsafe queries, isolation Multi-cause incidents with downstream symptom amplification Visible symptom points away from the true root cause
scan prolongs the order-api transaction. Because that transaction holds the lock on a session row while it scans, checkout workers queue behind it and surface only the downstream symptoms: lock waits and write timeouts. The DBA reference diagnosis has four logical hops: the initial timeout alert leads to the lock queue, the queue identifies an active slow holder, the holder’s plan reveals cardinality underestimation, and the estimate error leads to stale statistics. The scenario metadata therefore records 𝐷𝑠 = 4. Its causal evidence is sparse among the metrics, concurrent sessions, business SQL, and routine logs exposed by the required diagnostic tools, resulting in 𝐶𝑠 > 0.9. The scenario receives the aggregate Hard label. A response that terminates the visible blocker leaves the stale statistics intact and the fault recurs. A successful agent maps the lock chain, compares estimated and actual cardinalities, inspects the table statistics, and refreshes the target table with ANALYZE; the scenario verifier then checks that the workload no longer produces the lock waits and write timeouts.
5
Hard 10 13 8 7 8 10 8
This outcome-first definition distinguishes the realized operational result from the submitted causal account: outcome establishes whether the scenario-specific success contract was satisfied, while diagnosis separately tests whether the submitted causal account was correct. Outcome correctness asks whether the agent satisfies the scenario’s task-specific success contract. For every valid run, the evaluator emits a normalized fix-effectiveness value 𝐹𝑠 (𝑎) ∈ [0, 1], and Outcome Pass is the exact full-contract verdict 𝑂𝑠 (𝑎) = 1[𝐹𝑠 (𝑎) = 1] ,
𝐹𝑠 (𝑎) = 𝑉𝑠 (𝐸𝑠𝑎 , 𝑟𝑠𝑎 , 𝜏𝑠𝑎 ).
The verifier primarily checks the post-run database state and structured task artifacts. When the task contract requires targeted remediation or an explicit post-fix check, it also examines the corresponding action records. General path quality and destructive behavior remain separate evaluation dimensions. Success contracts reflect the task domain. (1) Query tuning. The target workload must improve and the intended plan or database state must take effect. (2) System failure. The affected operation or service must recover and the triggering fault state must be cleared. (3) Periodic health check. The requested findings, supporting evidence, and recommendations must be persisted; when remediation is requested, the resulting state must also change. (4) Business change. The requested schema, data, index, or configuration state must hold while continuity and integrity are preserved. (5) Resource governance. The designated policy must be enforced while protected roles, workloads, and access paths remain functional. (6) Composite faults. All causes must be remediated and service must be restored. (7) Misleading alerts. The true causal fault must be resolved without acting on the decoy, and the target operation must be rechecked. These contracts are executable predicates rather than free-form grading prompts: verifiers query database state, rerun target operations, and inspect the task artifacts needed for the declared outcome. Diagnostic accuracy asks whether the agent identified the causal fault, not merely a symptom. Let 𝐻𝑠 be the scenario’s reb𝑠 (𝑎) the normalized conditions quired root-cause conditions and 𝐻 submitted by the agent. We score their agreement with the set-based F1 measure:
Evaluation Protocol
Evaluation in DBA-Bench is defined over the task-specific success contract of an agent run. For each scenario, the benchmark restores a dirty environment, records the agent’s trace and structured submission, and applies a scenario-specific outcome verifier. DBABench reports three evaluation dimensions: correctness, safety, and efficiency. Correctness has two components: whether the agent satisfied the scenario’s task-specific success contract, and whether it identified the causal fault it was supposed to address. Formally, let 𝑠 denote a scenario, 𝐸𝑠0 its restored dirty environment, 𝑎 an evaluated agent, and 𝐸𝑠𝑎 the post-fix environment after 𝑎 stops. The full evaluation record is the output of the evaluator defined in Section 3.1: 𝑅𝑠 (𝑎) = J𝑠 (𝐸𝑠𝑎 , 𝜏𝑠𝑎 ) = 𝑄𝑠 (𝑎), 𝑆𝑠 (𝑎), Eff 𝑠 (𝑎) . The fields are reported separately rather than collapsed into a single score: correctness, safety, and efficiency answer different evaluation questions.
5.1
Easy 8 11 6 5 8 2 2
Correctness: Outcome and Diagnosis
Correctness measures whether the agent solved the right operational problem. It consists of outcome correctness and diagnostic accuracy: 𝑄𝑠 (𝑎) = 𝑂𝑠 (𝑎), 𝐴𝑠 (𝑎) .
𝐴𝑠 (𝑎) = 7
b𝑠 (𝑎)| 2|𝐻𝑠 ∩ 𝐻 , b𝑠 (𝑎)| |𝐻𝑠 | + |𝐻
𝐴𝑠 (𝑎) ∈ [0, 1],
where conditions cover root-cause types, causal factors, and affected entities. Scenario metadata declares accepted aliases, a critical subset 𝐻𝑠crit , and a set 𝐵𝑠 of contradictory diagnoses. The matcher retains unmatched submitted conditions as false positives. A run diag has 𝛿𝑠 (𝑎) = 1 only when 𝐴𝑠 (𝑎) ≥ 0.8, all critical conditions b𝑠 (𝑎) ∩ 𝐵𝑠 = ∅; otherwise it is zero. Free-form are present, and 𝐻 narrative and hidden reasoning do not affect the score. Outcome correctness and diagnostic accuracy are both correctness signals, but they capture different failure modes. An agent can fix a scenario by accident without identifying the root cause, or identify the root cause without executing a repair that restores the environment. Reporting both components separates reliable remediation from lucky repair and from diagnosis-only behavior.
5.2
comprise the instructions, task context, and accumulated interaction context presented to the model. KV caching reuses previously computed key–value states for repeated context. Cached input tokens therefore enter Token Cost at a lower provider rate than ordinary input tokens. Output tokens comprise all content generated by the model during the run. Let 𝑝𝑎in , 𝑝𝑎cache , and 𝑝𝑎out be the corresponding prices in USD per million tokens. The per-run Token Cost and efficiency record are 1 h Cost𝑠 (𝑎) = 6 𝑝𝑎in 𝑁𝑠in (𝑎) − 𝑁𝑠cache (𝑎) 10 i (1) + 𝑝 cache 𝑁 cache (𝑎) + 𝑝 out 𝑁 out (𝑎) , 𝑎
Eff 𝑠 (𝑎) =
𝑠
𝑎
𝑠
𝑁𝑠in (𝑎), 𝑁𝑠cache (𝑎), 𝑁𝑠out (𝑎), Cost𝑠 (𝑎) .
We use the frozen provider price table associated with the evaluation date and reconstruct costs from the recorded model calls. These are normalized list-price estimates rather than provider billing records. Token Cost does not affect correctness or safety.
Operational Safety
Safety scoring is risk-aware rather than write-averse. DBA-Bench does not penalize state-changing operations simply because they are powerful: many database faults require write-side remediation or instance control. Instead, it penalizes unnecessary, unscoped, unsupported, or destructive use of such operations. A high-risk action can be safe when it is justified by evidence, constrained in scope, consistent with the scenario’s operational assumptions, and followed by verification. The same action is unsafe when it violates an explicit scenario constraint or is issued without the required evidence, scope guard, or post-action check. Safety analysis is performed over SQL and instance-management traces. Inherently destructive operations, such as dropping data objects or truncating tables, are flagged unless explicitly required by the scenario. Scope errors, such as unconstrained DELETE or UPDATE, are penalized. Context-dependent operations, such as lockheavy maintenance, session termination, restart, or configuration change, are judged by whether the trace shows sufficient evidence, appropriate constraints, and post-action verification. This lets DBABench distinguish professional remediation from “fix by force” behavior that happens to improve the final metric. At the scoring level, scenario metadata defines the applicable safety rules and explicit exceptions as 𝐺𝑠 . Safety risk is the weighted penalty ∑︁ 𝑆𝑠 (𝑎) = 𝜆𝑔 1 𝑔 is violated in 𝜏𝑠𝑎 ,
5.4
Reported Experimental Metrics
The experiments summarize the per-scenario evaluation records with four reported metrics. Safe Pass is the primary endpoint because it measures production-acceptable task completion; Outcome Pass and Diagnosis Pass are secondary metrics that isolate recovery and causal understanding. For an evaluated scenario set S, Diagnosis Pass (DP) averages the per-run diagnosis verdict above, while Outcome Pass (OP) is the fraction that pass the scenario verifier: 1 ∑︁ diag 𝛿𝑠 (𝑎), DP(𝑎) = |S| 𝑠∈S 1 ∑︁ 𝑂𝑠 (𝑎). OP(𝑎) = |S| 𝑠∈S
An attempt that exhausts the agent’s assigned budget, produces an invalid structured submission, or terminates without a report receives neither an outcome nor a diagnosis pass. Safe Pass (SP) requires both outcome recovery and zero recorded safety risk. We report 1 ∑︁ SP(𝑎) = 𝑂𝑠 (𝑎) 1[𝑆𝑠 (𝑎) = 0] . |S| 𝑠∈S
where 𝜆𝑔 > 0 is the severity weight and the indicator is one when the trace violates rule 𝑔. A larger 𝑆𝑠 (𝑎) means greater operational risk. The run-level destructiveness_penalty field is 𝑆𝑠 (𝑎). Its exact-zero test defines Safe Pass, while its magnitude is retained as a secondary risk profile; no weighted composite score is used as a pass criterion. Because all weights are positive, they affect the severity profile but not the exact-zero test: 𝑆𝑠 (𝑎) = 0 if and only if no applicable rule is violated.
Thus, a run that restores the target state but violates any applicable safety rule does not count as a safe pass. All pass rates are scenarioweighted means over the same evaluated set, and the experiments additionally report each operational category separately. The aggregate therefore summarizes binary task-specific success contracts rather than pooling incomparable raw metrics. Token Cost reports the mean end-to-end model cost per evaluated scenario: 1 ∑︁ Cost(𝑎) = Cost𝑠 (𝑎), |S|
5.3
using the per-run accounting in Equation 1. It is N/A for human DBAs because their runs contain no model calls.
𝑔∈𝐺𝑠
𝑠∈S
Efficiency
Efficiency measures the end-to-end token expenditure of one run, from the scenario prompt through the final structured submission. Let 𝑁𝑠in (𝑎) be the input tokens processed across all model calls, 𝑁𝑠cache (𝑎) the subset of input tokens served from the provider’s cache, and 𝑁𝑠out (𝑎) the tokens generated by the model. Input tokens
6
Experiments
We design the experiments to measure not only whether current agents can complete DBA-Bench scenarios, but where they fail under workload-active, stateful database conditions and which 8
Table 2: Evaluated baseline groups. Group Frontier LLMs
Baselines GPT-5.5; Claude Opus 4.8; GLM-5.1; Qwen3.7-Max; DeepSeek V4 Pro Qwen3-Coder-Next
Open-weight LLMs DB-specific agents D-Bot (GPT-5.5); DBAIOps (GPT-5.5) Human reference
Human DBA
independently reimplemented the knowledge-graph-guided architecture described in its paper [38]. The post-fix verifier reflects operations issued through the DBA-Bench tool API; advisory recommendations remain trace records. Human DBA baseline. The Human DBA baseline uses the same initial symptom, dirty snapshot, tool boundary, safety constraints, and final submission schema as the agent runs. Human submissions are scored by the same outcome verifier, diagnosis scorer, and safety scorer. The analysis contains one valid Human DBA result for each of the 106 scenarios. Token Cost applies to model calls and is therefore N/A for Human DBA runs. Table 2 summarizes the evaluated groups and their experimental roles.
Experimental role Model capability under ReAct Model capability under ReAct Fixed-backbone system comparison Human reference
existing database-agent mechanisms remain insufficient for safe end-to-end remediation.
6.1
Experimental Setup
Run configuration. The PostgreSQL evaluation contains 106 unique scenarios across seven operational categories and the Easy/Hard labels defined in Section 4.2. It contains one run for each pairing of the 106 scenarios and eight automated baselines, yielding 848 automated runs; the Human DBA reference contributes 106 separately reported runs. Each evaluated run starts from the pre-generated dirty snapshot for its scenario. The harness reruns the scenario’s manifestation predicates before exposing the task, records the complete interaction, and restores the snapshot before the next run. The primary comparison is a single-run pass@1 evaluation, and its primary endpoint is Safe Pass. For the primary evaluation, we record the provider’s decoding configuration and experiment seed for every run. Where an API exposes explicit decoding controls, temperature and top-p are fixed; where it does not, the provider’s documented nondeterminism is retained. The primary score contains one run per evaluated baseline–scenario pair. Task input and knowledge access. Each automated run presents the scenario’s initial symptom and operational context as a DBA request or automated alert. It follows the common tool and submission interfaces defined in Section 3.3. All automated baselines access the same corpus of official PostgreSQL documentation [27] and operational SOPs through the knowledge-base tool. As specified in Section 3.3.3, retrieval is agentcontrolled: no scenario-specific passages are pre-injected, and each system must select the operational evidence and knowledge entries it inspects. Agent integration protocol. We use a common minimal ReAct Think– Act–Observe loop [33] to evaluate foundation-model capability. All frontier and open-weight LLMs receive the same tool schemas, knowledge access, safety instruction, trace logging, and submission format; only the foundation model changes. We then fix GPT-5.5 as the backbone and compare the ReAct reference with D-Bot’s tree-search strategy and DBAIOps’s knowledge-graph-guided strategy. This fixed-backbone comparison evaluates the agent systems while controlling model choice; architecture-specific control and implementation remain part of each system. Our D-Bot baseline adapts the public DB-GPT implementation1 , preserving its core algorithms while integrating it with DBA-Bench’s common tool, knowledge, trace, and submission interfaces. No public DBAIOps implementation was available at the time of evaluation, so we
6.2
End-to-end Performance
We evaluate end-to-end scenario completion with human DBAs as a reference. Foundation-model baselines use the common ReAct setup, while D-Bot and DBAIOps use GPT-5.5 as the fixed backbone. Safe Pass is the primary endpoint; Diagnosis Pass, Outcome Pass, and Token Cost explain causal understanding, realized outcome, and cost as defined in Section 5.4. Figure 3 jointly reports overall and category-level performance, the fixed-backbone system comparison, and the gap to human DBAs. The automated systems form a clear performance ordering. GPT5.5 and Claude Opus 4.8 form the leading tier at 17.9% Safe Pass. GLM-5.1, Qwen3.7-Max, and DBAIOps form a second cluster at 14.2– 15.1%, followed by DeepSeek V4 Pro at 10.4%; D-Bot and Qwen3Coder-Next remain below 6%. Human DBA reaches 93.4% Safe Pass, leaving a 75.5-percentage-point gap to the best automated result. The aggregate metrics expose a diagnosis-to-remediation bottleneck. Across the 848 automated runs, Diagnosis, Outcome, and Safe Pass are 32.7%, 19.6%, and 12.4%, respectively. Among the 848 automated runs, 277 achieve Diagnosis Pass, yet 172 of these (62.1%) fail Outcome Pass. Agents therefore often localize the root cause without completing the repair. No automated baseline leads Safe Pass in every category, so the overall ordering does not imply uniform superiority across operational domains. Performance–cost trade-off. Figure 4 relates Safe Pass to the mean USD Token Cost from Equation 1. We construct the Pareto frontier by treating lower cost and higher Safe Pass as preferable. Across all systems with defined Token Cost, the frontier contains DeepSeek V4 Pro, DBAIOps, GLM-5.1, and Claude Opus 4.8. If Safe Pass alone drives selection, GPT-5.5 and Claude Opus 4.8 tie for first. Once cost is included, Claude Opus 4.8 dominates GPT5.5 by matching its Safe Pass at a 36.5% lower mean cost. DBAIOps and GLM-5.1 occupy intermediate operating points: relative to GPT5.5, they reduce Safe Pass by 3.7 and 2.8 percentage points while reducing mean cost by 69.1% and 59.3%, respectively. DeepSeek V4 Pro marks the low-cost end of the frontier at $0.0803 per run and 10.4% Safe Pass. These lower-cost frontier points may be more practical for high-volume deployment, where per-run cost accumulates across repeated tasks. D-Bot records 5.7% Safe Pass at $7.1564 per run, compared with 17.9% at $1.0210 for the common-ReAct GPT-5.5 system.
1 https://github.com/TsinghuaDatabaseGroup/DB-GPT
9
Safe Pass
Outcome Pass
(b) Query tuning n = 18
(a) Overall n = 106
Diagnosis Pass
(c) System failure n = 24
(d) Health check n = 14
GPT-5.5 Claude Opus 4.8 GLM-5.1 Qwen3.7-Max DeepSeek V4 Pro Qwen3-Coder-Next D-Bot (GPT-5.5) DBAIOps (GPT-5.5) Human DBA 0
50
100 0
50
50
100 0
50
(e) Business change n = 12
100 0
(f) Resource governance n = 16
50
100 0
50
100 0
(g) Composite faults n = 12
50
100
50
100
(h) Misleading alerts n = 10
GPT-5.5 Claude Opus 4.8 GLM-5.1 Qwen3.7-Max DeepSeek V4 Pro Qwen3-Coder-Next D-Bot (GPT-5.5) DBAIOps (GPT-5.5) Human DBA 0
100 0 Success rate (%)
Figure 3: PostgreSQL Safe Pass, Outcome Pass, and Diagnosis Pass overall and across seven scenario categories. The legend follows that metric order; two gray separators distinguish model, database-agent, and Human DBA groups. Each panel title reports its number of unique scenarios (𝑛). Frontier LLM
Open-weight LLM
Safe Pass (%)
30
runs, with 26.1% Outcome Pass; deep diagnosis contains 83 scenarios and 664 automated runs, with 17.8%. The depth gap varies across systems: D-Bot records 30.4% on Direct and 8.4% on Deep scenarios, DeepSeek V4 Pro records 26.1% and 13.3%, and Qwen3-Coder-Next records 17.4% and 7.2%, whereas GPT-5.5 records 26.1% and 26.5%. Low environmental complexity contains 7 scenarios and 56 automated runs, with 25.0% Outcome Pass; high complexity contains 99 scenarios and 792 automated runs, with 19.2%. Across automated runs, Outcome Pass falls by 16.9 percentage points from Easy to Hard, 8.3 percentage points from Direct to Deep diagnosis, and 5.8 percentage points from Low to High environmental complexity. The consistent aggregate decline identifies deeper causal chains and denser, noisier evidence environments as practical barriers for agents: more competing signals make it harder to separate causal evidence from noise, localize the root cause, and complete a repair. Task domains and trace-level failures. We connect these capability boundaries to observable failures across the seven categories in Table 1: query tuning, system failure, periodic health check, business change, resource governance, composite faults, and misleading alerts. Figure 3 reports the category-level pass rates, while Figure 6 classifies 700 evaluator-readable non-clean runs by one dominant failure label. An LLM-as-a-judge classifier assigns the label from each recorded trace. A clean recovery must restore the required environment state without an unacceptable operational action. Runs that miss the outcome are diagnosis failures when causal localization is inadequate, and remediation failures when the cause is identified but repair selection, execution, coupling, or verification is incorrect. Runs that restore the outcome while violating a safety constraint are unsafe
DB-specific agent
GPT-5.5 Claude Opus 4.8 Qwen3.7-Max
20
GLM-5.1
10
DeepSeek V4 Pro
D-Bot
DBAIOps
0
Qwen3-Coder-Next
10−1
100
101
Mean verified token cost (USD / valid run)
Figure 4: PostgreSQL Safe Pass–mean Token Cost trade-off. The line marks the Pareto frontier.
6.3
Capability Boundaries
The main-results overview says how often each system succeeds. Figure 5 next exposes the aggregate Easy-to-Hard performance drop and two capability boundaries that underlie it: deep causal diagnosis and noisy operational environments. The scenario annotations support descriptive, non-causal comparisons of these factors. Difficulty, depth, and complexity. Easy contains 42 scenarios and 336 automated runs, with 29.8% Outcome Pass; Hard contains 64 scenarios and 512 automated runs, with 12.9%. We further disaggregate Outcome Pass by the two attributes underlying this difficulty label. Direct diagnosis contains 23 scenarios and 184 automated
10
(a) Difficulty
(b) Diagnostic depth
Easy
Hard
25
50
Direct
(c) Environmental complexity
Deep
Low
High
GPT-5.5 Claude Opus 4.8 GLM-5.1 Qwen3.7-Max DeepSeek V4 Pro Qwen3-Coder-Next D-Bot (GPT-5.5) DBAIOps (GPT-5.5) Human DBA 0
75
100
0
25
50
75
100
0
25
50
75
100
Outcome Pass (%)
Figure 5: PostgreSQL capability boundaries. Panel (a) reports Outcome Pass by Easy/Hard difficulty; panel (b) reports Outcome Pass by diagnostic depth; panel (c) reports Outcome Pass by environmental complexity. Diagnosis Omit
Misread
Query tuning
15%
System failure
13%
Remediation
Noise
Chain
Target
Partial
27%
Business
12%
Governance
28%
Verify
35%
n=119 n=150
0
20
n=80 n=100
20%
n=85
20% 68%
Alerts
n=103
10%
46%
13%
40
60
Safeguard
11% 15%
30% 19%
Scope
24% 21%
21%
Composite
Destructive
10%
18% 33%
Health check
Unsafe recovery
Execute
80
n=63
100
Share of non-clean runs (%) Figure 6: Failure-mode composition by scenario category across 700 evaluator-readable non-clean runs. Each 𝑛 is the number of runs included in the analysis for that category. recoveries. Secondary labels capture evidence omission or misinterpretation, noise anchoring, causal-chain truncation, wrong or partial repair, ineffective execution, unclosed verification, protectedobject or unscoped actions, and missing safeguards. Each run contributes exactly one dominant label, so the segments within each category sum to 100%; the displayed 𝑛 values give the number of included runs. The composition differs substantially across task categories. Noise/decoy anchoring dominates misleading-alert failures (68.3%), whereas causal-chain truncation dominates composite faults (45.9%). Wrong remediation target or action is the most frequent mode for system failures (34.7%) and business changes (30.0%), while decisive evidence omission leads periodic health checks (33.0%) and resource governance (28.0%). Query-tuning failures are more evenly divided
between evidence misinterpretation (26.9%) and an unclosed verification loop (24.4%). Aggregate pass rates therefore conceal distinct diagnostic and remediation bottlenecks across operational domains.
6.4
Safety and Operational Risk
Outcome recovery is necessary but not sufficient for operationally acceptable database repair. Necessary write operations are not themselves safety violations; an outcome-restoring path is unsafe when it touches a protected object, exceeds the evidence-supported scope, or omits safeguards required by the scenario. We therefore evaluate execution-path safety separately from whether the path restores the target state. The Outcome–Safe gap in Figure 3 makes this separation consequential: of the 166 automated runs that restore the required outcome, 61 (36.7%) fail Safe Pass. Figure 6 examines a different 11
population, the 700 evaluator-readable non-clean runs, and assigns each trace one exclusive dominant label. Unsafe recovery accounts for 40 of these labels (5.7%). The first statistic measures safety failure conditional on outcome recovery; the second characterizes the failure composition of the non-clean trace cohort and does not estimate the prevalence or severity of all safety defects that may co-occur within a run. Of the 40 unsafe-recovery labels, 17 are unscoped interventions and 15 are missing operational safeguards, compared with 8 destructive or protected-object violations. Scope and safeguard failures therefore account for 32 of 40 cases (80.0%), showing that operational risk is expressed primarily through how a repair is bounded and controlled rather than only through explicitly destructive actions. Unsafe recovery appears in all seven task categories; the largest within-category shares occur in business change (7/80, 8.8%), resource governance (8/100, 8.0%), and query tuning (9/119, 7.6%). This cross-category spread motivates treating safety as a constraint on the full agent control loop rather than as a specialized check for nominally safety-oriented tasks.
6.5
hypothesis state explicit: agents must maintain competing explanations, seek disconfirming observations, and record which causal links remain unverified as the evidence surface expands. Agents do not close the repair safely. Correct localization does not reliably become a correct, verified intervention: 172 of the 277 diagnosis-passing runs (62.1%) fail Outcome. Wrong remediation targets or actions are the leading failure mode for system failures (34.7%) and business changes (30.0%), while query-tuning failures are split between evidence misinterpretation (26.9%) and an unclosed verification loop (24.4%). The same weakness appears after recovery: 61 of the 166 outcome-passing runs (36.7%) fail Safe Pass. Among the 40 exclusive unsafe-recovery labels in the 700run non-clean trace cohort, 17 are unscoped interventions and 15 omit operational safeguards, together accounting for 80.0% of unsafe labels. The lesson is that a final safety filter is too late. The agent should carry a repair contract through the whole control loop, including preconditions, affected objects, action coupling and ordering, evidence-supported scope, reversibility, lock impact, rollback conditions, expected state transitions, and post-action verification of the original incident. Architecture changes do not remove brittleness. Current systems remain far from reliable operation: the best automated Safe Pass is 17.9%, compared with 93.4% for the Human DBA reference, and no automated baseline leads every scenario category. The fixedbackbone comparison also shows no automatic payoff from adding a more elaborate reasoning architecture. DBAIOps reaches 14.2% Safe Pass at a mean cost of $0.3150, versus 17.9% at $1.0210 for GPT-5.5 ReAct; D-Bot reaches only 5.7% while costing $7.1564 per run. Thus tree search or knowledge-graph guidance can change the operating point without removing the underlying failure modes. The design lesson is to evaluate agents by end-to-end Safe Pass, category-level failure patterns, and cost together. A single diagnosis score or global ranking can hide a system that is expensive, unsafe, or brittle on a particular class of database incident.
Fixed-backbone Agent-System Comparison
Fixed-backbone comparison. With GPT-5.5 fixed as the backbone, we compare three evaluated agent systems under the same scenarios, tool boundary, knowledge content, and scoring protocol. The sequential ReAct system is the reference; D-Bot incorporates tree-search-based hypothesis expansion [40], while DBAIOps uses knowledge-graph-guided reasoning [38]. Figure 3 reports their Diagnosis, Outcome, and Safe Pass rates, while Figure 4 relates Safe Pass to mean Token Cost. GPT-5.5 ReAct records 44.3% Diagnosis Pass, 26.4% Outcome Pass, and 17.9% Safe Pass at a mean cost of $1.0210. DBAIOps records 38.7%, 23.6%, and 14.2%, respectively, at $0.3150. Relative to ReAct, DBAIOps therefore trades a 3.7-percentage-point reduction in Safe Pass for a 69.1% reduction in mean cost, placing it on the Pareto frontier in Figure 4. D-Bot records 18.9% Diagnosis Pass, 13.2% Outcome Pass, and 5.7% Safe Pass at $7.1564, yielding a less favorable performance–cost trade-off in this comparison. On Hard scenarios, Figure 3 shows the same ordering: GPT-5.5 ReAct records 40.6%/23.4%/17.2%, DBAIOps records 26.6%/12.5%/4.7%, and D-Bot records 4.7%/4.7%/0.0% for Diagnosis, Outcome, and Safe Pass.
8
Conclusion
Evaluations based on curated observations, recommendation-only answers, or non-reproducible testbeds can overestimate whether an LLM agent can diagnose and safely remediate a live database incident. We introduced DBA-Bench, an outcome-first benchmark that restores controlled dirty environments preserving selected operational properties, revalidates each scenario’s fault manifestation, and separately evaluates diagnosis, system recovery, operational safety, and efficiency. By exposing where agents lose the causal chain, follow operational noise, or fail to close the remediation loop, DBA-Bench provides a reproducible basis for measuring progress toward dependable database-operations agents. The complete scenarios and evaluation artifacts will be released publicly upon publication.
7 Discussion 7.1 Implications for Database-Agent Design Agents lose the causal thread. The first weakness is diagnostic continuity: agents often process individual signals without maintaining a coherent explanation across the incident. Only 277 of 848 automated runs (32.7%) pass Diagnosis, and 166 (19.6%) pass Outcome. Outcome Pass falls by 8.3 percentage points from Direct to Deep diagnostic paths and by 5.8 points from Low to High environmental complexity. The trace composition identifies the corresponding failure patterns: causal-chain truncation dominates compositefault failures (45.9%), noise/decoy anchoring dominates misleadingalert failures (68.3%), and decisive evidence omission leads periodic health checks (33.0%) and resource governance (28.0%). These results show why larger context windows or more retrieval alone are unlikely to solve the problem. The design lesson is to make
References [1] Toufique Ahmed, Supriyo Ghosh, Chetan Bansal, Thomas Zimmermann, Xuchao Zhang, and Saravan Rajmohan. 2023. Recommending Root-Cause and Mitigation Steps for Cloud Incidents using Large Language Models. In 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). 1737–1749. doi:10.1109/ ICSE48619.2023.00149 [2] Haicheng Chen, Wensheng Dou, Dong Wang, and Feng Qin. 2020. CoFI: Consistency-Guided Fault Injection for Cloud Systems. In Proceedings of the 12
[20] Xiaoze Liu, Zheng Yin, Chao Zhao, Congcong Ge, Lu Chen, Yunjun Gao, Dimeng Li, Ziting Wang, Gaozhong Liang, Jian Tan, and Feifei Li. 2022. PinSQL: Pinpoint Root Cause SQLs to Resolve Performance Issues in Cloud Databases. In 2022 IEEE 38th International Conference on Data Engineering (ICDE). IEEE, 2549–2561. doi:10.1109/ICDE53745.2022.00236 [21] Xiao Liu, Hao Yu, Hanchen Zhang, Yifan Xu, Xuanyu Lei, Hanyu Lai, Yu Gu, Hangliang Ding, Kaiwen Men, Kejuan Yang, Shudan Zhang, Xiang Deng, Aohan Zeng, Zhengxiao Du, Chenhui Zhang, Sheng Shen, Tianjun Zhang, Yu Su, Huan Sun, Minlie Huang, Yuxiao Dong, and Jie Tang. 2024. AgentBench: Evaluating LLMs as Agents. In International Conference on Learning Representations (ICLR). https://arxiv.org/abs/2308.03688 [22] Yuhe Liu, Changhua Pei, Longlong Xu, Bohan Chen, Mingze Sun, Zhirui Zhang, Yongqian Sun, Shenglin Zhang, Kun Wang, Haiming Zhang, Jianhui Li, Gaogang Xie, Xidao Wen, Xiaohui Nie, Minghua Ma, and Dan Pei. 2023. OpsEval: A Comprehensive IT Operations Benchmark Suite for Large Language Models. arXiv preprint arXiv:2310.07637 (2023). https://arxiv.org/abs/2310.07637 [23] Xianglin Lu, Zhe Xie, Zeyan Li, Mingjie Li, Xiaohui Nie, Nengwen Zhao, Qingyang Yu, Shenglin Zhang, Kaixin Sui, Lin Zhu, and Dan Pei. 2022. Generic and Robust Performance Diagnosis via Causal Inference for OLTP Database Systems. In 2022 22nd IEEE International Symposium on Cluster, Cloud and Internet Computing (CCGrid). IEEE, 655–664. doi:10.1109/CCGrid54584.2022.00075 [24] Minghua Ma, Zheng Yin, Shenglin Zhang, Sheng Wang, Christopher Zheng, Xinhao Jiang, Hanwen Hu, Cheng Luo, Yilin Li, Nengjun Qiu, Feifei Li, Changcheng Chen, and Dan Pei. 2020. Diagnosing Root Causes of Intermittent Slow Queries in Cloud Databases. Proceedings of the VLDB Endowment 13, 8 (2020), 1176–1189. doi:10.14778/3389133.3389136 [25] Grégoire Mialon, Clémentine Fourrier, Craig Swift, Thomas Wolf, Yann LeCun, and Thomas Scialom. 2024. GAIA: A Benchmark for General AI Assistants. In International Conference on Learning Representations (ICLR). https://arxiv.org/ abs/2311.12983 [26] Biao Ouyang, Yingying Zhang, Hanyin Cheng, Yang Shu, Chenjuan Guo, Bin Yang, Qingsong Wen, Lunting Fan, and Christian S. Jensen. 2024. RCRank: Multimodal Ranking of Root Causes of Slow Queries in Cloud Database Systems. Proceedings of the VLDB Endowment 18, 4 (2024), 1169–1182. doi:10.14778/3717755. 3717774 [27] PostgreSQL Global Development Group. 2026. PostgreSQL 16.14 Documentation. https://www.postgresql.org/docs/16/ Accessed 2026-07-20. [28] Vikramank Singh, Kapil Eknath Vaidya, Vinayshekhar Bannihatti Kumar, Sopan Khosla, Balakrishnan Narayanaswamy, Rashmi Gangadharaiah, and Tim Kraska. 2024. Panda: Performance Debugging for Databases using LLM Agents. In Conference on Innovative Data Systems Research (CIDR). https://www.cidrdb.org/ cidr2024/papers/p6-singh.pdf [29] Xudong Sun, Wenqing Luo, Jiawei Tyler Gu, Aishwarya Ganesan, Ramnatthan Alagappan, Michael Gasch, Lalith Suresh, and Tianyin Xu. 2022. Automatic Reliability Testing for Cluster Management Controllers. In 16th USENIX Symposium on Operating Systems Design and Implementation (OSDI 22). 143–159. https://www.usenix.org/conference/osdi22/presentation/sun [30] Dana Van Aken, Andrew Pavlo, Geoffrey J. Gordon, and Bohan Zhang. 2017. Automatic Database Management System Tuning Through Large-scale Machine Learning. In Proceedings of the 2017 ACM International Conference on Management of Data. 1009–1024. doi:10.1145/3035918.3064029 [31] Zefan Wang, Zichuan Liu, Yingying Zhang, Aoxiao Zhong, Jihong Wang, Fengbin Yin, Lunting Fan, Lingfei Wu, and Qingsong Wen. 2024. RCAgent: Cloud Root Cause Analysis by Autonomous Agents with Tool-Augmented Large Language Models. In Proceedings of the 33rd ACM International Conference on Information and Knowledge Management. 4966–4974. doi:10.1145/3627673.3680016 [32] John Yang, Akshara Prabhakar, Karthik Narasimhan, and Shunyu Yao. 2023. InterCode: Standardizing and Benchmarking Interactive Coding with Execution Feedback. In Advances in Neural Information Processing Systems 36. 23826–23854. doi:10.52202/075280-1035 [33] Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik R. Narasimhan, and Yuan Cao. 2023. ReAct: Synergizing Reasoning and Acting in Language Models. In The Eleventh International Conference on Learning Representations (ICLR). OpenReview.net. https://openreview.net/forum?id=WE_vluYUL-X [34] Dong Young Yoon, Ning Niu, and Barzan Mozafari. 2016. DBSherlock: A Performance Diagnostic Tool for Transactional Databases. In Proceedings of the 2016 International Conference on Management of Data. ACM, 1599–1614. doi:10.1145/2882903.2915218 [35] Zhaoyang Yu, Minghua Ma, Chaoyun Zhang, Si Qin, Yu Kang, Chetan Bansal, Saravan Rajmohan, Yingnong Dang, Changhua Pei, Dan Pei, Qingwei Lin, and Dongmei Zhang. 2024. MonitorAssistant: Simplifying Cloud Service Monitoring via Large Language Models. In Companion Proceedings of the 32nd ACM International Conference on the Foundations of Software Engineering. 38–49. doi:10.1145/3663529.3663826 [36] Shuyan Zhou, Frank F. Xu, Hao Zhu, Xuhui Zhou, Robert Lo, Abishek Sridhar, Xianyi Cheng, Tianyue Ou, Yonatan Bisk, Daniel Fried, Uri Alon, and Graham Neubig. 2024. WebArena: A Realistic Web Environment for Building Autonomous Agents. In International Conference on Learning Representations. https://arxiv.
35th IEEE/ACM International Conference on Automated Software Engineering. 536– 547. doi:10.1145/3324884.3416548 [3] Sibei Chen, Ju Fan, Bin Wu, Nan Tang, Chao Deng, Pengyi Wang, Ye Li, Jian Tan, Feifei Li, Jingren Zhou, and Xiaoyong Du. 2025. Automatic Database Configuration Debugging using Retrieval-Augmented Language Models. Proceedings of the ACM on Management of Data 3, 1 (2025), 1–27. doi:10.1145/3709663 [4] Xu Chen, Haitian Chen, Zibo Liang, Shuncheng Liu, Jinghong Wang, Kai Zeng, Han Su, and Kai Zheng. 2023. LEON: A New Framework for ML-Aided Query Optimization. Proceedings of the VLDB Endowment 16, 9 (2023), 2261–2273. doi:10.14778/3598581.3598597 [5] Xu Chen, Junmin Chen, Shuncheng Liu, Yuyang Xia, Zibo Liang, Xiaoming Qin, Kai Zeng, Han Su, and Kai Zheng. 2026. DBAgent: An RL-Based Agent for Autonomous Database Operations and Maintenance. Proceedings of the VLDB Endowment 19, 12 (2026). [6] Xu Chen, Shuncheng Liu, Tong Yuan, Tao Ye, Kai Zeng, Han Su, and Kai Zheng. 2025. Optimizing Block Skipping for High-Dimensional Data with Learned Adaptive Curve. Proceedings of the ACM on Management of Data 3, 1 (2025), 1–26. doi:10.1145/3709710 [7] Xu Chen, Zhen Wang, Shuncheng Liu, Yaliang Li, Kai Zeng, Bolin Ding, Jingren Zhou, Han Su, and Kai Zheng. 2023. BASE: Bridging the Gap between Cost and Latency for Query Optimization. Proceedings of the VLDB Endowment 16, 8 (2023), 1958–1966. doi:10.14778/3594512.3594525 [8] Xu Chen, Ximu Zeng, Yuze Wang, Zibo Liang, Kai Zeng, Han Su, and Kai Zheng. 2026. LEON+: Towards Robust ML-Aided Query Optimization. The VLDB Journal 35, 3 (2026), 21. doi:10.1007/s00778-026-00973-9 [9] Yinfang Chen, Manish Shetty, Gagan Somashekar, Minghua Ma, Yogesh Simmhan, Jonathan Mace, Chetan Bansal, Rujia Wang, and Saravan Rajmohan. 2025. AIOpsLab: A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds. In Proceedings of Machine Learning and Systems, Vol. 7. https://arxiv.org/abs/2501.06706 [10] Yinfang Chen, Huaibing Xie, Minghua Ma, Yu Kang, Xin Gao, Liu Shi, Yunjie Cao, Xuedong Gao, Hao Fan, Ming Wen, et al. 2024. Automatic Root Cause Analysis via Large Language Models for Cloud Incidents. In Proceedings of the Nineteenth European Conference on Computer Systems. 674–688. doi:10.1145/3627703.3629553 [11] Songqiao Han, Xiyang Hu, Hailiang Huang, Minqi Jiang, and Yue Zhao. 2022. ADBench: Anomaly Detection Benchmark. In Advances in Neural Information Processing Systems, Vol. 35. 32142–32159. https://papers.nips.cc/ paper_files/paper/2022/hash/cf93972b116ca5268827d575f2cc226b-AbstractDatasets_and_Benchmarks.html [12] Shiyue Huang, Ziwei Wang, Xinyi Zhang, Yaofeng Tu, Zhongliang Li, and Bin Cui. 2023. DBPA: A Benchmark for Transactional Database Performance Anomalies. Proceedings of the ACM on Management of Data 1, 1 (2023), 1–26. doi:10.1145/ 3588926 [13] Naman Jain, Manish Shetty, Tianjun Zhang, King Han, Koushik Sen, and Ion Stoica. 2024. R2E: Turning any GitHub Repository into a Programming Agent Environment. In Proceedings of the 41st International Conference on Machine Learning (Proceedings of Machine Learning Research, Vol. 235). 21196–21224. https: //proceedings.mlr.press/v235/jain24c.html [14] Yuxuan Jiang, Chaoyun Zhang, Shilin He, Zhihao Yang, Minghua Ma, Si Qin, Yu Kang, Yingnong Dang, Saravan Rajmohan, Qingwei Lin, and Dongmei Zhang. 2024. Xpert: Empowering Incident Management with Query Recommendations via Large Language Models. In Proceedings of the IEEE/ACM 46th International Conference on Software Engineering. 1–13. doi:10.1145/3597503.3639081 [15] Carlos E Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik Narasimhan. 2024. SWE-bench: Can Language Models Resolve RealWorld GitHub Issues?. In International Conference on Learning Representations. https://arxiv.org/abs/2310.06770 [16] Jiale Lao, Yibo Wang, Yufei Li, Jianping Wang, Yunjia Zhang, Zhiyuan Cheng, Wanghu Chen, Mingjie Tang, and Jianguo Wang. 2024. GPTuner: A ManualReading Database Tuning System via GPT-Guided Bayesian Optimization. Proceedings of the VLDB Endowment 17, 8 (2024), 1939–1952. doi:10.14778/3659437. 3659449 [17] Patrick Lewis, Ethan Perez, Aleksandra Piktus, Fabio Petroni, Vladimir Karpukhin, Naman Goyal, Heinrich Küttler, Mike Lewis, Wen-tau Yih, Tim Rocktäschel, Sebastian Riedel, and Douwe Kiela. 2020. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. In Advances in Neural Information Processing Systems 33. 9459–9474. https://proceedings.neurips.cc/paper/2020/hash/ 6b493230205f780e1bc26945df7481e5-Abstract.html [18] Zibo Liang, Xu Chen, Yuyang Xia, Runfan Ye, Haitian Chen, Jiandong Xie, and Kai Zheng. 2024. DACE: A Database-Agnostic Cost Estimator. In 2024 IEEE 40th International Conference on Data Engineering (ICDE). IEEE, 4925–4937. doi:10. 1109/ICDE60146.2024.00374 [19] Ping Liu, Shenglin Zhang, Yongqian Sun, Yuan Meng, Jiahai Yang, and Dan Pei. 2020. FluxInfer: Automatic Diagnosis of Performance Anomaly for Online Database System. In 2020 IEEE 39th International Performance Computing and Communications Conference (IPCCC). IEEE, 1–8. doi:10.1109/IPCCC50635.2020. 9391550 13
[39] Xuanhe Zhou, Lianyuan Jin, Ji Sun, Xinyang Zhao, Xiang Yu, Jianhua Feng, Shifu Li, Tianqing Wang, Kun Li, and Luyang Liu. 2021. DBMind: A Self-Driving Platform in openGauss. Proceedings of the VLDB Endowment 14, 12 (2021), 2743– 2746. doi:10.14778/3476311.3476334 [40] Xuanhe Zhou, Guoliang Li, Zhaoyan Sun, Zhiyuan Liu, Weize Chen, Jianming Wu, Jiesi Liu, Ruohang Feng, and Guoyang Zeng. 2024. D-Bot: Database Diagnosis System using Large Language Models. Proceedings of the VLDB Endowment 17, 10 (2024), 2514–2527. doi:10.14778/3675034.3675043
org/abs/2307.13854 [37] Wei Zhou, Ji Sun, Xuanhe Zhou, Guoliang Li, Luyang Liu, Hao Wu, and Tianyuan Wang. 2025. GaussMaster: An LLM-based Database Copilot System. arXiv preprint arXiv:2506.23322 (2025). https://arxiv.org/abs/2506.23322 [38] Wei Zhou, Peng Sun, Xuanhe Zhou, Qianglei Zang, Ji Xu, Tieying Zhang, Guoliang Li, and Fan Wu. 2026. DBAIOps: A Reasoning LLM-Enhanced Database Operation and Maintenance System using Knowledge Graphs. Proceedings of the VLDB Endowment 19, 6 (2026), 1319–1331. doi:10.14778/3797919.3797937
14