A Solo Engineer Spent $1,200 Training a 4B Model to Beat Postgres's Query Planner by 44.7%. That's a Blueprint for a Narrow AI Optimization Service.

A solo engineer spent $1,200 and beat Postgres's own query planner using a 4B-parameter model — and the pattern behind it is a repeatable service, not a one-off research result.

What actually happened

Rohan Bansal trained a 4B-parameter model — a distillation of Qwen from Empero — to generate Postgres query plans, using off-policy distillation via supervised fine-tuning followed by agentic reinforcement learning. He used LoRA to keep it cheap: just 21.2 million trainable parameters, a 42.5 MB adapter. Training data came from the Cardinality Estimation Benchmark (CEB), 13,646 queries across 16 templates, run against an 8.5 GB IMDb dataset. The held-out test was the Join Order Benchmark (JOB): 113 queries across 33 templates.

The results: a 1.81x geometric-mean speedup over Postgres's default plans, a 44.7% reduction in total summed latency across the 113 queries, and a win on 68 of 113 queries in a best-of-15 measurement, with zero regressions in a best-of-three scenario. Total cost was $1,200 — about $800 for a 2x H100 rental on Lambda over 95 hours, and about $400 in OpenAI API fees for generating training trajectories. The stack was PostgreSQL with the pg_hint_plan extension, vLLM for inference, and Prime Intellect's renderers and prime-rl libraries for the RL loop, all measured inside Docker containers for isolation.

What this exposes

• Query optimization is an easily verifiable-reward task — a plan either runs faster or it doesn't, which is exactly the kind of clean signal that makes small models trainable without massive labeled datasets
• LoRA keeps the deployment footprint tiny — a 42.5 MB adapter on top of an open base model is cheap to host, version, and swap per client workload
• The whole thing cost $1,200 — that's not a research-lab budget, it's a weekend-project budget, which means the barrier to piloting this kind of service is low
• The reported metrics are the ones a client can check themselves — win rate and total latency reduction, not just an averaged speedup number

The business idea

Any company running Postgres at scale with a library of recurring, slow, join-heavy queries is a candidate for a scoped version of this exact pipeline:

• Pull the client's own slow-query logs via pg_stat_statements instead of relying on a public benchmark
• Fine-tune a small open base model with LoRA against those real queries, using plan latency as the verifiable reward signal
• Validate on a held-out slice of the client's own query log, the same train/test split structure this project used between CEB and JOB
• Deliver the result as a lightweight adapter plus a report: queries improved, total latency reduction, and any regressions caught in testing
• Price the pilot against this project's own $1,200 cost baseline, since that's the number a technical buyer can sanity-check against a GPU rental calculator

Why this works now

Open base models, LoRA tooling, and RL frameworks like prime-rl have made this kind of narrow, verifiable-reward fine-tuning cheap enough that one engineer did it solo for $1,200. The gap between "interesting research post" and "sellable service" is just aiming the same pipeline at a paying client's actual workload instead of a public benchmark.

Bottom line

$1,200, a 4B model, and a verifiable reward signal beat Postgres's own planner by 44.7% on latency. That's a pilot-priced blueprint for anyone who wants to sell narrow AI optimization audits instead of general-purpose AI consulting.

Sources:

https://rohanbansal.com/qorl