Rohan Bansal spent $1,200 and 95 hours on rented hardware to train a language model that now outperforms one of the world's most popular databases at a task engineers have been trying to perfect for decades: figuring out the fastest way to run a query.
The independent researcher's experiment, published Tuesday, achieved something that has eluded years of academic work and millions in corporate R&D investment. His four-billion-parameter model generates PostgreSQL execution plans 81 percent faster than the database's built-in optimizer on certain workloads. The geometric-mean speedup of 1.81× and 44.7 percent reduction in total latency came from teaching a compact Qwen model to emit pg_hint_plan directives that steer PostgreSQL toward better join orders and scan methods. He tested on the Join Order Benchmark, a standard analytical stress test.
The result lands at an opportune moment. Cloud infrastructure spending hit $119.1 billion in the fourth quarter alone, according to Synergy Research's recent figures, and PostgreSQL has become the database of choice for modern applications. Stack Overflow's 2025 developer survey placed it first, with 47 percent of respondents planning to use it—a trend that has only strengthened in the year since. Yet traditional query optimizers still dominate production environments, and a VLDB survey published last year noted that learned approaches have struggled to gain traction beyond research labs.
Bansal demonstrated that a small, purpose-trained model can deliver measurable gains on join-heavy analytical workloads for roughly the cost of a weekend hardware rental. The approach sidesteps two problems that have plagued earlier attempts: the latency of invoking frontier models at query time and the expense of running them at scale.
When Good Enough Isn't Fast Enough
PostgreSQL's optimizer makes decisions about join order and scan methods using cost estimates derived from table statistics and heuristics. The system guarantees correctness—it will always produce a valid execution plan. Speed on every query? Not so much.
Engineers running analytics or reporting workloads regularly encounter cases where the default plan misses faster alternatives. Multi-table joins with complex predicates prove especially troublesome, particularly when cardinality estimates drift or when the optimizer's cost model fails to capture hardware realities like cache hierarchies or parallel execution benefits.
Commercial databases have started addressing this gap. Oracle's Automatic Indexing, detailed in a VLDB paper from 2025, reported roughly 15 percent performance gains and 60 percent space reclamation on customer workloads. Microsoft SQL Server's Intelligent Query Processing now includes Optional Parameter Plan Optimization and cardinality-estimation feedback extensions. IBM's Db2 applies neural approaches to join estimation. These systems operate within the vendor's optimizer, not by retrofitting external models onto open-source PostgreSQL.
The open-source community has explored learned optimizers for years with mixed results. Neo in 2019 generated plans directly via learning. Bao, introduced in 2020 and refined through 2022, applied bandit-style hints to steer existing optimizers. Balsa, presented at SIGMOD 2022, claimed gains up to 2.8× after hours of training on certain workloads. Lero, demonstrated at VLDB 2023, used learning-to-rank on top of Postgres and reported up to 70 percent plan-time reduction on some benchmarks.
None achieved mainstream production traction. Alibaba's MaxCompute team documented four persistent blockers in a SIGMOD Companion paper published in May 2026: variance in plan costs, missing statistics, the infeasibility of continual refinement, and uncertainty about which workloads actually benefit from learned optimization.
Convergence of Small Models and Real Feedback
Two technical shifts converged to enable Bansal's approach, and timing mattered. First, small language models became capable enough to handle structured prediction tasks. The 4B-parameter Qwen model, fine-tuned with a 21-million-parameter LoRA adapter, proved it could understand Postgres schema metadata, EXPLAIN output, and relation statistics, then propose syntactically valid pg_hint_plan directives.
Second, reinforcement learning from actual query runtimes closed the loop that earlier supervised methods lacked. Bansal's training recipe combined supervised fine-tuning from roughly 500 GPT-6 "Astra" agent trajectories with reinforcement learning using a GRPO-style reward based on measured execution time versus PostgreSQL defaults.
The cost equation proved critical. Google's BigQuery team wrote in a blog post from May 2026 that "LLM invocations add 10–100× to overall query latency and roughly 1000× on cost," motivating their development of proxy models more than 100 times faster and cheaper than direct frontier-model calls. Bansal paid approximately $800 to rent a dual-H100 node from Lambda for the training period and $400 in OpenAI API fees for the distillation stage.
"Total cost: $1,200," he wrote.
The model runs offline, materializing hints for recurring analytical queries rather than invoking inference per query in a transactional workload. Infrastructure availability helps too. AWS RDS, Google Cloud SQL, and Azure Database for PostgreSQL all support pg_hint_plan as a loadable extension, meaning engineering teams can deploy hint-based optimizations without forking the database engine. A February blog post from pganalyze suggested improved core mechanisms for influencing plans may arrive in future PostgreSQL versions, further lowering adoption friction.
The Experiment's Boundaries
Bansal trained the model on roughly 13,600 IMDb queries from the Cardinality Estimation Benchmark and evaluated it on the 113 queries of the Join Order Benchmark. That's a standard read-only workload on an eight-to-eight-and-a-half-gigabyte dataset that fits in memory.
The system gave the model tools to inspect relation statistics and EXPLAIN plans, propose up to 15 candidate hint sets per query, and measure actual runtime. The model learned to favor nested loops and index scans, often setting enable_sort=off and random_page_cost=1.1. It converged on three dominant strategies: rewriting join orders with the Leading hint, single-scan fixes, and enabling parallelism.
The 1.81× geometric-mean speedup came from selecting the fastest of the 15 candidates per query. Bansal controlled measurement noise by running concurrent PostgreSQL containers, executing warm-up runs until shared hit and read blocks stabilized, tuning shared_buffers to two gigabytes, interleaving candidate and default measurements, and clipping outliers.
The Hacker News discussion thread accumulated 673 points and 137 comments by mid-September, with readers raising generalization questions that matter. The workload was read-only. The dataset fit in RAM. Queries were warmed prior to measurement. These conditions don't hold for many production OLTP or hybrid workloads dealing with cold starts, write amplification, or variable cardinalities.
An arXiv paper from September 2023 titled "Is Your Learned Query Optimizer Behaving As You Expect?" documented cases where PostgreSQL outperformed multiple learned optimizers in standardized evaluations, depending on data splits. While the findings are now three years old, the evaluation pitfalls the authors highlighted—overfitting to template patterns and train-test leakage—remain relevant considerations. Bansal's experiment used the standard JOB benchmark and published measurement protocols, but the setup limits direct comparison to systems running diverse, unpredictable query mixes on terabyte-scale data.
Industry Context and Skepticism
Gartner forecast in a report from early 2026 that global DBMS end-user spending will grow 18.4 percent to roughly $161 billion, driven by cloud and AI workloads. DB-Engines has placed PostgreSQL among the top databases and fastest-growing systems in recent rankings. Demand-side pressure for better query performance is tangible.
Andy Pavlo, a Carnegie Mellon professor and co-founder of OtterTune, said in an interview in January 2026 that adaptive re-optimization during execution represents a frontier for commercial systems: getting feedback about optimizer decisions while a query runs and deciding whether to re-plan. Michael Stonebraker, a Turing Award winner, argued in a May 2026 summary that "upscaling data to tables and doing joins in a query optimizer" remains superior to pushing too much logic into LLM agents. He expressed skepticism about agentic pipelines replacing traditional database engines.
An ACM TIST survey published in August 2026 titled "Large Language Models in DBMS Optimization" cataloged LLM-based steering and embedding methods, identified open gaps in latency budgets and safety guardrails, and outlined the path to productionization. The survey noted that training-free plan similarity approaches and small specialized models trained with reinforcement learning or distillation show promise as "steering layers" atop mature optimizers. That's precisely the architecture Bansal demonstrated.
The Alibaba MaxCompute paper from May 2026 detailed variance in learned plan costs, missing statistics in multi-tenant warehouses, the infeasibility of continual model retraining, and uncertainty about which queries benefit. An offline, per-workload approach like Bansal's might partially sidestep these challenges by treating hint generation as a batch optimization task rather than a live inference service.
Deployment Realities
Bansal's work fits a pattern emerging across recent years: small, task-specific models trained with reinforcement learning from execution feedback, running offline to avoid latency penalties. The approach works for recurring analytical queries where a company can afford to invest hours of training and validation once, then materialize the resulting hints.
It does not replace live query planning on transactional workloads where sub-millisecond planning overhead matters and query patterns shift unpredictably.
Deployment risks center on hint stability. Statistics drift as data changes. A hint that accelerates a query on Monday's data may degrade performance by Friday. Engineers adopting this strategy will need re-optimization schedules, regression tracking, and fallback logic to disable hints when they stop helping. The pg_hint_plan extension emits debug information indicating whether hints were applied, enabling validation pipelines.
The broader ecosystem continues evolving. Microsoft's SQL Server team keeps expanding adaptive query-processing features with parameter-sensitivity fixes and plan corrections. Oracle shipped automatic indexing as a production feature. IBM's Db2 applies neural cardinality estimation. Google BigQuery built proxy models to avoid invoking expensive frontier LLMs in the query loop. Startups and research labs have published a cluster of LLM-based optimization papers exploring training-free and few-shot strategies. The PVLDB decade survey from 2025 concluded that learned optimizers "have not yet seen wide adoption in production," but the infrastructure and interest are aligning, perhaps more than the researchers expected.
What founders and technical leaders should watch: whether cloud providers integrate hint-based steering into managed PostgreSQL offerings, whether the core Postgres project adopts richer hinting primitives in upcoming versions, and whether vendors bundle small learned models as optional optimization layers.
The $1,200 price tag puts experimentation within reach of any engineering team running a slow analytics workload. The 81 percent speedup quantifies the gap between default plans and what a targeted search can find. The real test will come when teams apply the method to their own workloads—larger, colder, more variable—and measure whether the gains hold. Bansal's experiment suggests the answer might surprise traditional database engineers, even if production deployment remains several steps away.
