A 4B Model Just Beat Postgres's Query Planner by 81%

A 4B model just beat Postgres’s own query planner — producing plans that run 81% faster. That is a genuine speed win over software Postgres has spent decades tuning.

The claim comes from a project called Qorl, posted to Hacker News under the title “Training a 4B model to produce 81% faster query plans than Postgres.” The pitch: a 4-billion-parameter model, trained to generate execution plans, outpaces the cost-based optimizer that ships inside every stock Postgres install — the same component that decides join order, index usage, and scan strategy for every query your application runs.

This matters most to anyone running Postgres in production and feeling the tax of its planner on complex joins or analytical workloads: backend engineers at scale-up startups, data infrastructure teams, and indie founders who chose Postgres because it is free and everywhere, then hit its ceiling once query complexity grew. It also matters to anyone building tooling on top of small models, because this is a case where a 4B model — small enough to run cheaply, not a frontier model — is being pointed at a narrow, high-value systems problem instead of general chat.

The mechanism is the interesting part. Postgres’s planner works by estimating costs at query time, walking through statistics and heuristics before picking a plan. A trained model instead learns, ahead of time, what a good plan looks like for a given query shape and skips that live search. That trade — replacing a hand-tuned heuristic search with a model that has already seen enough queries to pattern-match a fast plan — is the same idea behind learned query optimizers researchers have chased for years. What is new here is the size: a 4B model is small enough to run inline, not as an offline research artifact.

What this does not mean yet: Postgres has not shipped this. There is no patch, no extension, no production deployment described. It is a benchmark result on Hacker News, not a merge into Postgres core. The open question for anyone tempted to act on it is whether this generalizes past whatever workload it was benchmarked on, and how it behaves when query shapes it was not trained on show up. Builders who work with small models on narrow systems problems will recognize this pattern from Show HN: Forge — a small model, aimed tightly, closing a gap that used to need something bigger. If you are stitching model-in-the-loop systems into production tooling, the shift toward agentic pipelines doing this kind of decision-making live is covered in The Autonomous Stack.

Get one AI signal like this a day, in your inbox, at /subscribe/.