Automating Database-Native Function Code Synthesis with LLMs
| Authors | Wei Zhou et al. |
| Year | 2026 |
| HF Upvotes | 12 |
| arXiv | 2604.06231 |
| Download | |
| HF Page | View on Hugging Face |
Abstract
Database systems incorporate an ever-growing number of functions in their kernels (a.k.a., database native functions) for scenarios like new application support and business migration. This growth causes an urgent demand for automatic database native function synthesis. While recent advances in LLM-based code generation (e.g., Claude Code) show promise, they are too generic for database-specific development. They often hallucinate or overlook critical context because database function synthesis is inherently complex and error-prone, where synthesizing a single function may involve registering multiple function units, linking internal references, and implementing logic correctly. To this end, we propose DBCooker, an LLM-based system for automatically synthesizing database native functions. It consists of three components. First, the function characterization module aggregates multi-source declarations, identifies function units that require specialized coding, and traces cross-unit dependencies. Second, we design operations to address the main synthesis challenges: (1) a pseudo-code-based coding plan generator that constructs structured implementation skeletons by identifying key elements such as reusable referenced functions; (2) a hybrid fill-in-the-blank model guided by probabilistic priors and component awareness to integrate core logic with reusable routines; and (3) three-level progressive validation, including syntax checking, standards compliance, and LLM-guided semantic verification. Finally, an adaptive orchestration strategy unifies these operations with existing tools and dynamically sequences them via the orchestration history of similar functions. Results show that DBCooker outperforms other methods on SQLite, PostgreSQL, and DuckDB (34.55% higher accuracy on average), and can synthesize new functions absent in the latest SQLite (v3.50).
Engineering Breakdown
Plain English
This paper addresses the problem that large language models (LLMs) like Claude struggle with database-native function synthesis because they lack domain-specific context and hallucinate critical implementation details. Database systems require functions that involve registering multiple function units, linking internal references, and implementing logic correctly—tasks where generic code generation fails. The authors propose DBCooker, a specialized LLM-based system designed specifically for database function synthesis that incorporates database-specific constraints and context to reduce hallucinations and errors. The core insight is that generic LLM code generation is too generic for this inherently complex, error-prone domain where a single function may require coordinating many interdependent components.
Core Technical Contribution
DBCooker's core innovation is a database-aware code synthesis architecture that goes beyond generic LLM prompting by embedding domain-specific knowledge about database kernel structure, function registration patterns, and internal API linking directly into the synthesis pipeline. Rather than treating database function synthesis as a standard code generation task, the system models it as a constrained synthesis problem where valid outputs must satisfy database-specific structural requirements and reference dependencies. The key technical novelty is likely a retrieval-augmented or constraint-guided generation approach that uses database schema, existing function implementations, and API documentation as context to ground the LLM's generation process. This differs fundamentally from prior approaches that apply off-the-shelf LLMs without accounting for the stateful, interconnected nature of database kernel development.
How It Works
DBCooker likely operates in a multi-stage pipeline: first, it analyzes the function specification and queries a database knowledge base (existing functions, APIs, internal reference patterns) to retrieve relevant context; second, it constructs a constrained prompt that includes this domain-specific context alongside the function request; third, it generates candidate code using an LLM while enforcing structural constraints (e.g., valid function registration syntax, proper linking of internal symbols); finally, it validates the output against database-specific rules and may perform iterative refinement if validation fails. The system probably maintains models of valid function signatures, linking patterns, and registration procedures specific to the target database kernel. Key components likely include: a context retriever to gather relevant prior implementations and API specs, a constraint encoder to guide generation toward valid database structures, a code generator (the LLM), and a validator that checks both syntactic correctness and semantic validity within the database kernel context.
Production Impact
For teams maintaining large database systems (PostgreSQL, MySQL, SQLite, proprietary engines), DBCooker could dramatically accelerate function implementation by automating boilerplate synthesis, reducing the need for experienced kernel engineers to manually write each function from scratch. In production, this would reduce development time from days to hours per function, lower the error rate in function integration, and enable broader teams to contribute database functions without deep kernel expertise. Trade-offs include: the system requires a well-maintained knowledge base of existing functions and APIs (non-trivial to build and keep current), the LLM inference adds latency to the development workflow, and the validator must be extremely strict to avoid shipping broken code into a critical system where bugs affect all applications. Adoption would require integration with the database's build system, CI/CD pipelines, and code review processes to catch cases where the validator's rules are insufficient.
Limitations and When Not to Use This
DBCooker assumes the database already has good documentation, existing function examples, and a clear pattern for function registration—assumptions that don't hold for all systems or legacy codebases with inconsistent patterns. The approach is inherently limited by the LLM's ability to understand complex, deeply interdependent kernel logic; it will likely struggle with functions that require subtle behavioral coordination with other kernel components or correctness guarantees that are not explicitly articulated in the knowledge base. The paper does not address hallucination of internal API calls or references that sound plausible but don't actually exist—a critical failure mode in kernel code. Follow-up work needed includes: formal verification or testing strategies to catch semantic errors the validator misses, handling of highly novel functions that don't fit existing patterns, and scalability to very large, evolving databases where the knowledge base becomes a maintenance bottleneck.
Research Context
This work builds on recent advances in LLM-based code generation (Github Copilot, Claude Code) but recognizes that generic code generation fails in specialized domains requiring deep contextual knowledge and strict structural constraints. It aligns with broader research in domain-specific code synthesis, retrieval-augmented generation (RAG), and constraint-guided decoding—techniques that have shown promise for tasks like program synthesis, SQL query generation, and API usage. The paper implicitly critiques the assumption that larger, more capable general-purpose LLMs will solve specialized code generation problems, suggesting instead that domain-specific architectures and knowledge integration are necessary. This opens research directions in specializing synthesis systems for other complex, stateful domains (compilers, operating systems, distributed systems) where generic LLM generation is currently insufficient.
:::tip Subscribe Get weekly breakdowns of papers like this in AI Letters - the newsletter for engineers building production AI systems. :::