Are LLMs Overkill for Databases?: A Study on the Finiteness of SQL

Yue Li, David Mimno, Unso Eun Seo Jo
3/26/2026
cs.DBcs.AI

No confident code implementation found for this paper.

Abstract

Translating natural language to SQL for data retrieval has become more accessible thanks to code generation LLMs. But how hard is it to generate SQL code? While databases can become unbounded in complexity, the complexity of queries is bounded by real life utility and human needs. With a sample of 376 databases, we show that SQL queries, as translations of natural language questions are finite in practical complexity. There is no clear monotonic relationship between increases in database table count and increases in complexity of SQL queries. In their template forms, SQL queries follow a Power Law-like distribution of frequency where 70% of our tested queries can be covered with just 13% of all template types, indicating that the high majority of SQL queries are predictable. This suggests that while LLMs for code generation can be useful, in the domain of database access, they may be operating in a narrow, highly formulaic space where templates could be safer, cheaper, and auditable.

View on arXivView PDF

Code Implementations

No confident code match yet

We couldn't find an author-owned or strongly-evidenced community implementation for this paper. Any repos shown below are weak matches — verify before relying on them.

No code implementations found yet.

Know of an implementation? Let us know in the comments below!

Similar Papers

Cite this paper

@article{li2026llms,
  title  = {Are LLMs Overkill for Databases?: A Study on the Finiteness of SQL},
  author = {Yue Li and David Mimno and Unso Eun Seo Jo},
  year   = {2026},
  eprint = {2603.25568},
  archivePrefix = {arXiv},
  url    = {http://arxiv.org/abs/2603.25568v1}
}

Add a badge to your README

Shows whether official code is linked for this paper.

Code of Paper badge
[![Code of Paper](https://codeofpaper.com/badge/2603.25568.svg)](https://codeofpaper.com/paper/2603.25568)

Discussion