Papers for

database application developers

Papers whose findings have a practical use for this group, as judged from the abstract. Open a paper to read what it means in practice.

Air system resolves ambiguous questions for accurate text to SQL

Probing Ambiguity: Adversarial Intent Resolution for Robust Text-to-SQL

Abstract: Text-to-SQL systems typically assume a one-to-one mapping between natural-language queries and correct SQL translations. In practice, however, many queries are inherently ambiguous, admitting multiple valid interpretations that yield distinct outputs. We introduce Adversarial Intent Resolution (AIR), a multi-agent framework that actively probes and resolves such ambiguity without any task-specific training. AIR first constructs competing interpretations, verifies through SQL execution that they produce genuinely different results, and generates targeted clarification questions grounded in the observed data differences. Evaluating on leading benchmarks for ambiguous questions, AIR demonstrates strong performance, efficiency, and robust cross-benchmark transferability. On the AMBROSIA benchmark under schema-only context, a realistic production setting where exposing the full database is infeasible, AIR outperforms IntentRL, the state-of-the-art reinforcement learning model, across all metrics (e.g., F1 0.679 vs. 0.618). Crucially, AIR exhibits only ~7% performance degradation without the full database, compared to ~20% for IntentRL. On the AmbiQT benchmark, where ambiguity arises from schema design rather than linguistic structure, AIR achieves higher F1 under both context settings without any benchmark-specific adaptation.

Fri 16 OctArtificial IntelligenceComputation and Language
The gist
Many natural language questions can be understood in more than one way, making it hard for computers to translate them into the right database queries. The authors present a system called AIR that creates different possible SQL queries, checks if they lead to different answers, and then generates simple questions to clarify the user's intent. This approach works well without needing special training and performs better than earlier methods on standard tests. It also handles cases where the full data isn't available, making it useful in real-world settings.
Open → 2610.24248v1

Text to sql systems learn to spot and refuse flawed requests

PremiseSQL: Evaluating Premise Critique and Abstention in Text-to-SQL Systems

Abstract: Recent advances in large language models (LLMs) have substantially improved Text-to-SQL performance, yet existing NL2SQL systems largely assume that user queries are valid and answerable. As a result, models often generate executable SQL even for queries with flawed premises. We introduce premise critique ability in NL2SQL, namely the ability to recognize flawed queries and abstain from generating misleading SQL. To evaluate this capability, we propose PremiseSQL, a benchmark containing 1,800 flawed NL2SQL queries across four categories of premise failures, along with their 1,800 original queries. We further design an evaluation framework to measure intrinsic and prompt-induced premise-aware behavior across three prompting settings. Experiments on frontier LLMs show that current models are strongly premise-trusting by default and rarely critique flawed premises. Stronger critique-oriented prompting improves detection and abstention on flawed queries, but also increases false invalid judgments and suppresses SQL generation on originals. The code is available at https://github.com/vegeet/PremiseSQL.

Thu 15 OctComputation and Language
The gist
Text-to-SQL systems translate natural language questions into database queries but often assume all questions are valid. This can lead to incorrect or misleading database commands if the input is flawed. The authors created PremiseSQL, a test set of flawed queries and original versions, to check if systems can recognize and refuse to answer invalid questions. They found current language models usually trust flawed queries and rarely reject them, though special prompting can help balance detection and correct response.
Open → 2610.22158v1

HarnessSQL improves sql agent accuracy by training with live databases

HarnessSQL: Harness-Native Training for SQL Agents in Realistic Database Environments

Abstract: Text-to-SQL models are commonly trained to map questions directly to static queries, whereas real-world database agents operate through stateful, multi-turn interaction with live databases -- inspecting schemas, executing probe queries, diagnosing errors, and revising hypotheses. This creates a critical train-deploy mismatch, as the execution harness that mediates this interaction is introduced only at inference time. To bridge this gap, we propose HarnessSQL, a harness-native post-training framework that preserves the full interaction structure throughout both supervised fine-tuning and reinforcement learning. HarnessSQL builds isolated, executable database environments paired with hidden execution oracles, rolls out teachers directly inside the target SQL harness, and retains only verified trajectories for full-sequence SFT, followed by execution-reward RL. Across Spider 2.0-SQLite, HarnessSQL dramatically boosts the execution accuracy of compact models, raising Qwen3-8B from 15.5% to 45.2% and Qwen3-14B from 22.2% to 54.8%, while transferring effectively to out-of-distribution interactive benchmarks such as BIRD-Interact and LiveSQLBench. Our findings demonstrate that training database agents directly within their execution harness is essential for mastering complex, long-horizon database workflows.

Thu 8 OctComputation and Language
The gist
Many AI programs that turn questions into database queries learn by making a single guess, but real use involves asking many questions and trying out queries step-by-step. The authors found that this difference makes these programs less accurate when used in practice. They created HarnessSQL, a method that trains these programs by letting them practice interacting with live databases during learning. This approach greatly improved the accuracy of compact models and worked well even on new types of databases.
Open → 2610.12274v1

Database agents use contracts to check and explain query results

No Trace, No Claim: Two Contracts for Database Agents

Abstract: LLM agents can generate database operations and explain their results, but current interfaces often leave a gap between generated plans, execution conditions, and claims presented to users. We argue that agent-facing data systems need two enforceable contracts. A plan contract defines what an agent may execute and reference; an evidence contract records the belief state, completeness, and provenance under which a result supports a claim. We instantiate these contracts in TGMS, a bi-temporal graph system in which an LLM plans over a fixed temporal operator interface. A static verifier checks plans before execution, and a claim verifier checks typed claims against content-addressed traces. Live model runs exposed two failures missed by input-only schemas and value-only grounding: nonexistent result fields and page-local counts reported as complete-result counts. Result-field checking makes the first a repairable rejection. Completeness propagation detects the second in all 15 controlled cases and misses all 15 when disabled. On the frozen CollegeMsg workload, TGMS reaches 0.408 typed-answer accuracy versus 0.064--0.284 for the evaluated baselines. On Bitcoin-OTC, direct SQL over the same bi-temporal store matches TGMS, showing no universal accuracy advantage for the fixed operator interface. On correction probes, TGMS and bi-temporal SQL answer historical-belief questions, while latest-state baselines cannot. Before claim gating, 21 of 220 answers contain an unsupported gated claim; after gating, none of 199 emitted answers does, at the cost of 21 fewer answers. The plan contract makes invalid plans rejectable and execution reproducible under recorded conditions, while the evidence contract makes gated claims faithful to cited evidence. Neither guarantees correct interpretation of user intent.

Wed 7 OctDatabases
The gist
It can be tricky for AI agents to explain how they got results from databases and whether those results are reliable. The authors propose two kinds of rules, or contracts, that these agents should follow: one about what the agent is allowed to do, and another about how it shows evidence supporting its answers. They built a system called TGMS that uses these contracts to catch errors and make sure answers match the evidence. This helps produce more trustworthy and verifiable answers from AI database agents.
Open → 2610.09286v1

DbRAG improves answering complex questions using multiple database tables

DBRAG: Multi-Table Retrieval-Augmented Generation for Complex Database Queries

Abstract: Recent advancements in large language models have introduced new capabilities for reasoning over structured data, particularly through program-aided tools that can analyze tables. However, many existing methods address single-table scenarios or assume that the relevant tables are already provided. In practice, users often issue complex data exploration queries over entire databases, where relevant information may be distributed across multiple relations. In this work, we introduce DBRAG, a retrieval-augmented generation framework tailored for multi-table question answering. DBRAG first retrieves candidate tables using an offline table index, enriches their summaries with query-relevant rows, and uses an LLM to rerank the candidates. A program-aided reasoner then selects the required tables and executes operations over their full contents, keeping the initial prompt context compact. Experiments on the Spider, GeoQuery, and ATIS datasets used in this study demonstrate improvements in table retrieval and multi-table question answering.

Tue 6 OctInformation Retrieval
The gist
Complex questions about data often need information from many database tables, but most tools only handle one table or assume the right tables are already known. The authors developed DBRAG, a system that first finds likely useful tables across a whole database and then uses a smart language model to pick and combine data from those tables. This helps answer complicated queries better by looking at multiple sources at once. They tested DBRAG on several standard datasets and found it works better at finding relevant tables and producing accurate answers.
Open → 2610.07622v1

Agentic text to sql systems improve question handling to reduce hidden errors

Beyond Correctness: Resolving Underspecification in Agentic Text-to-SQL

Abstract: Agentic Text-to-SQL systems can interact with users to clarify underspecified queries before generating SQL. However, a correct execution result does not necessarily imply that the agent has adequately resolved the underlying underspecification: the agent may silently make unverified assumptions that happen to match the intended answer. We show that this behavior is driven in part by premature clarification termination. Although forcing an agent to ask more questions improves execution accuracy, ambiguities are concentrated in earlier interactions, making brute-force questioning inefficient. More importantly, even when explicitly prompted to plan its clarification process, the agent frequently abandons questions that it has already identified as relevant. To address this failure mode, we introduce PlanPool, which externalizes the clarification plan as a mutable question pool. Every planned question must be explicitly asked or dropped before submission, while newly discovered ambiguities can be added during interaction. Across three benchmarks derived from BIRD-Interact and Spider, PlanPool consistently improves ambiguity coverage and reduces silent failures over unconstrained and prompt-based alternatives, while maintaining competitive execution accuracy. Our results highlight an important distinction in agentic reasoning: identifying missing information is not sufficient, and the agent must also reliably maintain and resolve it before committing to an answer.

Fri 2 OctComputation and Language
The gist
Sometimes, systems that turn natural language questions into database queries don’t ask enough questions to clarify unclear requests. This can lead the system to guess answers that seem correct but may not truly match what the user wanted. The authors show that these systems often stop asking questions too soon or forget to ask important ones. They introduce a new method called PlanPool, which keeps track of questions the system plans to ask and ensures they are all addressed before giving a final answer. This approach improves how well the system covers unclear parts of a question and reduces silent errors while still answering accurately.
Open → 2610.02739v1

Enforcing database rules with VBA and SQL Server code

On Enforcing Database Constraints Using MS VBA Event Driven Procedures and SQL Server

Abstract: The goal of this paper is to provide a rigorous methodology for enforcing database constraints using MS VBA event-driven procedures for software applications built on top of MS SQL Server databases, in the framework of the software engineering Database Constraint-Driven Design and Development. The original contribution is a pseudo-code algorithm for assisting developers in this process. We exemplify the results of using it with some VBA code examples taken from a genealogy database software application designed and developed using this methodology. Consequently, it enforces all the database constraints -be they relational or not- which govern this sub-universe of discourse, thus guaranteeing the highest possible quality of its managed data. We also show that the proposed algorithm works fine not only for other relational database management systems, but even with NoSQL platform backends, and that the modifications needed to adapt it to other similar SQL embedding frontend platforms are minimal.

Wed 30 SeptDatabases
The gist
Many software programs need to keep their data accurate by following strict rules called constraints. This paper explains how to use Microsoft VBA code inside applications to automatically enforce those data rules when working with SQL Server databases. The authors provide a clear step-by-step method and example code from a family tree database to show how this enforcement works. They also demonstrate that their approach can be adapted easily for other database systems, including some that aren’t strictly relational.
Open → 2610.00633v1

Automated prefetching improves database traversal speed up to three times

Automated Prefetching for Object Spatial Programming Using Temporal Trace Graphs

Abstract: Dependent database accesses can serialize application--database round trips on a request's critical path. Planning across traversal steps requires knowing both which relationships a computation may follow and how discovered objects become subsequent execution contexts. We identify a programming-model contract that exposes this information through inspectable access paths and explicit traversal continuation. We demonstrate this contract in Object-Spatial Programming (OSP), where walkers traverse a typed object graph and execute node-type-specific code. We introduce the Temporal Trace Graph (TTG), a bounded, request-specific graph of candidate objects and traversal-derived transitions. At walker spawn, the TTG Builder composes statically extracted access and continuation rules over the live graph from the request's starting node. An asynchronous prefetcher loads planned objects while the walker executes. We implement TTG in Jac/PostgreSQL and evaluate four applications covering linear, multi-hop, recursive, and value-dependent traversals. TTG improves end-to-end latency in three applications, achieving up to 2.99x speedup over the stock runtime. Comparisons with manually staged prefetching characterize the benefits and costs of automatic cross-step planning. The evaluation also shows that planning overhead can exceed avoided demand latency and that value-dependent control can introduce bounded overfetch.

Tue 29 SeptDatabasesProgramming Languages
The gist
Many programs need to fetch related pieces of data one after another, which can slow things down. The authors propose a way to plan these fetches ahead of time by understanding how a program explores data objects and where it might go next. They create a special graph that helps predict which data to load early, speeding up the process. Testing this idea on four programs showed it can make some tasks almost three times faster, though sometimes the planning itself costs extra time.
Open → 2609.38439v1