Trained 4B model beats Postgres query planner by 81% on join-heavy queries

A developer reports that a 4-billion-parameter open-weights model, post-trained with supervised fine-tuning and agentic reinforcement learning, can produce Postgres query plans that outperform the database's own planner. According to the technical write-up by Rohan Bansal that reached the Hacker News front page, the model delivered a 44.7% latency reduction across 113 join-heavy queries, which the author frames as plans running roughly 81% faster than Postgres's defaults.

A decade-old shortcoming

The experiment begins from an uncomfortable finding. When Leis et al. asked how good query optimizers really are in 2015, and revisited the question ten years later, the answer had barely improved despite years of research. Bansal writes that this surprised him, since a database should, in principle, know everything about the data sitting in its own tables.

The core difficulty is join ordering, a problem that is formally NP-hard. On top of choosing which tables to join in which sequence, the planner must pick a join algorithm (hash, merge or nested loop), an outer and inner orientation for each join, and a scan strategy for every table (sequential, index, index-only or bitmap). For a single three-table query against a slice of the IMDb dataset, Bansal counts 4,608 distinct plans, and notes that this is an undercount because it ignores options such as parallel execution and hashed versus sorted aggregation. Postgres does not enumerate all of them: it prunes the search space with dynamic programming and switches to a genetic algorithm for queries involving twelve or more joins.

Where plans go wrong

Bansal illustrates the stakes with a query about Japanese production companies. Without filtering conditions, both valid join orders for the three tables feed the same two million rows into the second join. Adding selective predicates changes everything: if roughly 5% of companies are Japanese and 20% of titles date from the 2000s, one ordering funnels about 100,000 rows into the second join while the alternative pushes roughly 400,000 through. That is four times the work for an identical answer, and picking the cheaper path depends on cardinality estimates that lean on assumptions such as uniform data distribution.

Why reinforcement learning fits

The post's central observation is that although generating a good plan is very hard, verifying one is trivial: execute it and measure the time. Because there is a single, objective reward signal, the problem collapses into reinforcing the behaviors that lead to faster plans, a setting where language models tend to perform well.

The training setup

The methodology highlights, as listed by the author, include:

• Starting from a base 4B model that could not produce a valid query plan for 99 of the 113 benchmark queries, yet ending with a 44.7% latency reduction across the set.
• A custom GRPO variant built to score reinforcement learning rollouts in an inherently noisy measurement environment.
• A Postgres benchmarking rig engineered to reduce Linux page cache contention noise across concurrent containers.
• A two-machine training split, with vLLM inference and the trainer running on a rented dual-H100 node and four Postgres containers running on the author's own desk.
• Off-policy distillation from roughly five hundred GPT-6 Astra agent trajectories.

Why it matters

Query optimization is one of the longest-standing pain points in database engineering, and the Leis et al. follow-up suggests conventional approaches have plateaued. If a compact model can consistently choose materially better plans than a mature, battle-tested planner, it points to a practical path for machine learning to slot into database internals, where the reward is cheap to measure and correctness is enforced by execution itself.

The result also offers a template beyond databases: any infrastructure task with an objective score, such as index selection, query rewriting or scheduler tuning, could be approached the same way.

Caveats apply. The evaluation covers 113 join-heavy queries, the work is a single-author experiment rather than a peer-reviewed study, and replacing a production planner would require handling far more of the SQL surface than join ordering. But as a demonstration that a small open model can learn to plan better than one of the most widely deployed optimizers in the world, it marks a notable data point for AI-assisted systems software.