Why LLMs Write Incorrect SQL (and What That Means for Your Database)

AI-assisted development has made it easier than ever to generate SQL quickly. The problem is that quick and correct are not the same thing, and with databases, the gap between the two has real consequences.

LLMs are good at producing SQL that looks right. It parses, it runs, and it returns results. What it frequently gets wrong is the logic underneath: incorrect joins that multiply rows, aggregations applied to the wrong grouping level, missing WHERE clauses that quietly scan entire tables, or filter conditions that return plausible but semantically wrong results. These are not bugs that fail loudly. They fail silently, returning data that looks reasonable until someone checks it against reality.

• The surface problem is hallucination. The deeper problem is load. A hallucinated column or fabricated table name will throw an error. More dangerous is SQL that executes but does the wrong thing: a COUNT that double-counts due to a bad join, or a GROUP BY that aggregates at the wrong granularity. These queries hit your database repeatedly, often at scale, and each one carries the full execution cost of a legitimate query.
• Schema complexity makes it worse. LLMs are trained on public schemas and benchmark datasets. Production schemas are messier: ambiguous column names, denormalized structures, business logic baked into table design. The further your schema is from what the model was trained on, the more likely it is to generate queries that are structurally valid but logically wrong.
• The correctness bar for SQL is higher than for most code. A wrong function in application code often produces a visible error or a failed test. A wrong SQL query often produces a result set that is plausible enough to go unquestioned. In database contexts, where performance invariants and data correctness are tightly coupled, that is a meaningful risk.
• Governance is starting to catch up. Teams shipping AI-generated SQL to production are beginning to treat query review the way they treat code review: validation layers, execution plan checks, and in some cases, replay testing against known results. The tooling is still taking shape, but the pattern is emerging.

The goal isn't to avoid using LLMs for SQL. The problem is that incorrect or unoptimized queries don't just risk wrong results; they land on your database at full execution cost, repeatedly, often before anyone notices. Understanding where LLMs fail is the first step to knowing what your database is actually being asked to do.

🔍 What We're Watching in the Database Ecosystem

MariaDB Innovation: InnoDB-Based Binary Log

MariaDB 12.3 ships a significant architectural change: binary log events stored directly in InnoDB-managed tablespaces rather than flat files. The result is fewer fsyncs, better crash safety, and in some benchmarks, dramatically higher write throughput under production-safe settings. If you've been following our MySQL binary log series, this is a complementary read on where the format itself is heading.

Which LLM Writes the Best Analytical SQL?

Tinybird benchmarked 19 LLMs against 50 analytical queries on a 200 million row dataset. The results are worth reading carefully: models frequently return data without returning correct data, with flawed joins, wrong timestamps, and overly broad filters that bloat query cost. A useful empirical counterweight to the assumption that LLM-generated SQL is production-ready.

In Case You Missed It

New on our blog: Replication Internals: Decoding the MySQL Binary Log, Part 3

Marcelo continues the series with a deep dive into the Format Description Event, the first event written to every binary log file and the key to how MySQL describes its own replication format. If you're building on top of replication or working with CDC tooling, this is the one that ties the format together.

And if you missed last week's announcement: join us for the Introducing Readyset Shallow Cache webinar, which will be a close look at how Shallow Cache works and what it means for your stack.