Agent-written database code can be fast without deciding what is true

The result that matters is not the largest speedup

A new database-systems paper reports that an agent-generated cardinality estimator reduced end-to-end PostgreSQL query runtime by 33% on JOB and 68% on JOB-Complex, relative to plans chosen with PostgreSQL’s default estimates. In Section 3.1, beside Figure 2, the authors write that these results close “around 75% of the execution-time gap (headroom)” between PostgreSQL estimates and offline true cardinalities. Those are workload-specific measurements, not a text-to-SQL leaderboard result—but they test an increasingly important question: where can generated database code improve performance without gaining authority over the answer? The paper calls its answer a “correctness firewall.”

Three boundaries, three different costs

The first pattern is advisory. The synthesized estimator may influence access paths and join order, but SQL execution still determines the result. A bad estimate can make a query slower; by itself, it cannot make a semantically valid plan return different rows. Section 3.1 says the estimator “advises the optimizer” but “can never cause the optimizer to pick an incorrect plan.” That restricted interface is why the JOB result is narrower and more defensible than a claim that an agent generated an entire correct database engine.

The second pattern is guarded. For sorted arrays, the agent produced a pure C function that predicts a key’s insertion position. The system checks the neighboring values; if the position is invalid, it falls back to binary search. Section 3.2 reports that the bound condition in Equation 1 “was never violated in these experiments” across integer and URL-string data. Figure 3 supplies the space/time comparison; the paper’s abstract summarizes the best result as up to 3× faster than human-designed learned indexes. The check still has a cost: Section 3.2 explicitly notes the additional condition check, while the paper’s research agenda calls for measuring firewall overhead directly.

The third pattern is domain-certified. An agent synthesizes a decompressor for one immutable file, and deployment is allowed only after exhaustive reconstruction of that file succeeds. In Section 3.3, beside Figure 4, the authors report that on Yelp, one generated codec had “similar decompression speed to Zstandard” with a compression factor “nearly 50% better.” The same section says the certification applies to “that one file”; it does not generalize to another file.

What the benchmark does not prove

The definition in Section 2 assumes synthesized programs are deterministic, halt, do not crash and do not modify state outside their scope. Section 4 repeats the operational forms of those assumptions—no process crash or segfault, no infinite loop and no out-of-scope state mutation—and calls the guarantees difficult or, for arbitrary-program halting, impossible to establish in practice.

The lifecycle boundary is equally explicit. Section 4 says an index guard must see “the same array snapshot as the search,” because a concurrent change can invalidate the proposed position. It also says a decoder certificate belongs to a particular codec and compressed file and “does not automatically apply when the data is updated.”

The benchmark therefore supports a narrower conclusion than “agents can safely write databases.” It shows that interfaces can be designed so generated components affect speed but not query semantics, under declared safety and lifecycle assumptions. The next evaluation should measure guard overhead, fallback frequency under distribution shift, synthesis and statistics-collection cost, concurrency behavior and adversarial failures. Until then, the strongest result is architectural: generated code is safest when the trusted database remains the final judge.