AI Query Optimization vs. Postgres: An Experiment in Owning the Planner

AI query optimization already beats Postgres's native planner in published benchmarks, by margins from single digits to nearly 70 percent.¹² Nobody has proven that a small, cheaply trained model can deliver those gains as something a team owns outright, rather than a feature rented from a managed database vendor. That's the actual open question here: not whether AI can beat the planner, that's settled, but whether you can own the thing that beats it.

The premise: a planner you train instead of a planner you're issued

Postgres's query planner is free. You don't pay a subscription for it. But its intelligence is fixed at whatever the community shipped in your version. You can tune parameters, add indexes, rewrite queries. You can't teach it anything new about your specific workload the way you'd fine-tune a model.

That's the frame this piece tests. If a learned optimizer can beat Postgres's cost-based planner by double digits, and fine-tuning a small model now costs less than a nice dinner, then "AI query optimization" stops being a research curiosity and becomes an ownership question: build a planner you control, or keep renting one bundled into whatever managed Postgres tier you're paying for.

How does Postgres's planner work, and why is it replaceable?

Postgres uses a cost-based optimizer. For any given query, it enumerates possible execution plans, join orders, index choices, scan types, estimates the cost of each against table statistics, and picks the cheapest one it finds. The catch: those cost estimates are just estimates. They rest on assumptions about data distribution that don't always hold, and the join-ordering search space grows fast enough that the planner has to prune it heavily on complex queries.

Here's what makes this whole experiment possible: Postgres exposes hooks, literal function pointers the planner calls at specific moments, that let you intercept and override its behavior without touching a line of Postgres's C source.³ You don't need to fork Postgres to change how it plans queries. You need to write something that plugs into a hook that already exists.

That architectural fact is why this isn't a thought experiment. The plumbing for AI query optimization already exists inside Postgres. Someone just has to build the model that uses it.

The prior art: Bao, Neo, and LLM-QO already did this

Learned query optimizers aren't hypothetical. They're a small but real research lineage, and the results beat what most DBAs assume.

• Bao, built at MIT CSAIL and Intel Labs, plugs into Postgres through the same hook architecture described above and steers the native planner with coarse-grained hints, things like disabling nested loop joins for a specific query, chosen through reinforcement learning. Across three real workloads on Google Cloud, Bao cut cost and latency by roughly 50 percent versus native Postgres, and about 20 percent versus a tuned commercial database.¹ It trained in about an hour, not days.¹
• Neo, an earlier system from largely the same research group, used reinforcement learning to tailor plan choices to the latency actually observed on a specific database instance, framed explicitly as a tool to improve "thousands of applications which rely on PostgreSQL."⁴
• LLM-QO, a 2025 system, drops plan enumeration entirely and reframes query optimization as text generation: a fine-tuned LLM reads the query, table statistics, and a reference plan, then generates the plan directly. Fine-tuned through a two-stage pipeline, Query Instruction Tuning followed by Query Direct Preference Optimization, on open-source model backbones with LoRA, it beat Postgres's built-in optimizer by 5.6 percent on IMDB, 8.6 percent on JOB-light, and 68.7 percent on the DSB benchmark.²

None of these systems replace Postgres. All three sit on top of it, steering or generating plans that the same execution engine runs. That distinction matters for everything that follows.

Why a 4B model, not a 175B one

The instinct is to reach for a frontier model. That's the wrong instinct here, and it's a cost argument, not a capability one.

Query planning is narrow and repetitive. The input format is constrained (SQL plus statistics), the output format is constrained (a plan), and the domain doesn't require general reasoning about the world. NVIDIA's own research on agentic tasks argues that small language models, roughly under 10 billion parameters, are sufficiently capable for exactly this kind of narrow job, and run 10 to 30 times cheaper than frontier models while fine-tuning in a few GPU hours instead of days.

That economic gap compounds with how cheap fine-tuning has gotten in general. QLoRA fine-tuning of a 7B-8B model on a marketplace GPU now runs $3 to $15 in compute.⁵ A 4B model targeted at one narrow task, plan generation over one schema, sits well inside that range. This is the same math behind tuning a local model to reason like the API it replaced: the model isn't the bottleneck. The configuration and training data are.

The experiment: training a 4B model to plan queries

Here's what building this actually looks like, following the LLM-QO recipe scaled down to a model one team could own.

1. Build the training corpus. Collect real queries against your actual schema, along with table statistics and reference execution plans, mirroring the QInstruct data format LLM-QO used to encode SQL, stats, and plans as structured text.²
2. Instruction-tune first. Run a Query Instruction Tuning pass so the model learns the mapping from query-plus-stats to a valid plan, the same first stage LLM-QO used before preference tuning.²
3. Preference-tune second. Apply a DPO-style pass, ranking candidate plans by actual execution cost so the model learns to prefer cheaper plans over merely valid ones, following LLM-QO's QDPO stage.²
4. Wire it into Postgres via the hook. Deploy the model's output as hints through the same planner_hook mechanism Bao and pg_hint_plan already use, so the native planner still executes but takes direction from the model.¹³⁶
5. Evaluate against a held-out workload, not the training set. This is where most of the field has cut corners, and it's the subject of the next section.

Where it breaks: tail catastrophe and the trust problem

This is where the promotional version of this story falls apart, and where the honest version starts.

A rigorous independent benchmarking study out of Zurich University of Applied Sciences re-evaluated six published learned query optimizers, Neo, Balsa, Lero, LEON, RTOS, and HybridQO, and found that once train/test splits and covariate shift are properly controlled for, Postgres's native optimizer wins in almost all experiments.⁷ The headline numbers in individual papers often hold up on the benchmark they were tuned against and nowhere else.

Bao's own paper is candid about a second failure mode: learned optimizers, on average, beat traditional ones, but sometimes regress catastrophically on individual queries, up to 100 times worse than the traditional planner would have chosen.⁸ Bao's fix is architectural. It constrains its own hint space to a limited set of options, which bounds how far a bad choice can drift from optimal, though the source notes this also means Bao isn't always able to find the best possible plan.¹⁸

There's a third problem, less about numbers and more about operations. A black-box model's plan choice is harder for a DBA to debug than a cost-based optimizer's explainable cost estimate. When the traditional planner picks a bad plan, you read EXPLAIN ANALYZE and see why. When a fine-tuned model picks a bad plan, you're debugging a neural network's judgment call at 2am.

What does owning your planner cost compared to renting Postgres?

Set the ownership case against real rent. One team reported paying $12,000 a month for a single multi-AZ RDS Postgres instance with 10TB of storage, and they were still burning engineering hours fighting IOPS limits on top of that bill.⁹ Postgres itself runs 49 percent of developers, per the 2024 Stack Overflow survey, the most popular database for the second year in a row.¹⁰ This isn't a niche exercise. It's the default database for most teams reading this.

Against that, the marginal cost of an owned, fine-tuned 4B planning model is close to zero once it's trained. Training itself runs in the tens of dollars.⁵ The real cost isn't compute, it's the engineering time to build the training corpus, wire in the hook, and monitor for tail regressions, the same tradeoff covered in the playbook for self-hosting a company's AI stack: the model is cheap, the plan for owning it is the actual work. Teams already running their own inference layer instead of renting it from a vendor, using something like Remy to host fine-tuned models internally, are the ones positioned to actually run this experiment instead of just reading about it.

Verdict: is this a real contest yet?

Partially. AI query optimization already wins clearly in the steering role. Bao's hint-based approach delivers real, reproducible gains on top of Postgres's own planner, with low training cost and bounded downside.¹⁸ LLM-QO shows a small fine-tuned model can generate competitive or better plans on specific benchmarks.² Neither requires replacing Postgres. Both require owning a layer on top of it.

Full replacement of the cost-based planner isn't there yet. The Zurich benchmarking work is a fair warning that most learned optimizers don't generalize past the workload they were built on, and the tail-catastrophe risk is real enough that nobody serious is ripping out their cost-based optimizer for a model.⁷ "Extreme software ownership" today looks less like replacing Postgres's core and more like this: a cheap, narrow, owned model sitting inside Postgres's own extension points, steering decisions the native planner still makes, with a human able to override it the moment it goes wrong. That's not a smaller ambition than replacing the planner outright. It's the version that survives contact with a production incident.