Bansal argues that by training directly on wall-clock execution time as the reward signal, QoRL bypasses the fundamentally broken cardinality estimation step that cripples traditional cost-based optimizers. His 81% average speedup on the benchmark suite is presented as evidence that learned plans can beat hand-tuned heuristics without requiring accurate row-count predictions.
Bansal emphasizes that QoRL outputs valid Postgres plan trees that drop into the existing executor unchanged — no forked build, no C-level surgery. Combined with single-digit millisecond inference time on an 8×H100 node, he positions this as engineering-ready rather than a lab curiosity.
The editorial highlights that QoRL's inference latency is in the same order of magnitude as Postgres's native planner (milliseconds vs microseconds-to-milliseconds), not off by 1000×. This framing treats the deployability question as the real bar, and argues QoRL clears it.
The editorial frames the significance of QoRL through the lens of a long-standing structural failure in relational databases: cardinality estimation errors of 10×–1000× on multi-join queries are documented across the literature. This positions any approach that avoids cardinality estimation as inherently promising, regardless of the specific model architecture.
By submitting the post and driving it to 537 points and 115 comments in a day, polyphilz signals that the community treats this as a significant result. The editorial notes this level of engagement is unusual for database-internals content that isn't announcing an outage, suggesting broad developer interest in learned query optimization.
Rohan Bansal published results from QoRL — a 4-billion-parameter model trained with reinforcement learning to emit Postgres query plans directly. On his benchmark suite, plans produced by QoRL executed 81% faster on average than plans chosen by Postgres 16's built-in optimizer. The submission hit 537 points on Hacker News within a day, which is unusual for a database-internals post that isn't announcing an outage.
The setup is straightforward in a way that older ML-for-databases papers weren't. QoRL takes the parsed query and schema statistics as input and outputs a plan tree in the same shape Postgres's planner produces — join order, join algorithms, scan methods, the whole thing. Because the output is a valid Postgres plan, it plugs into the executor unchanged; no custom runtime, no C-level surgery, no forked build. The reward during training is simply wall-clock execution time of the emitted plan on the target instance, measured directly rather than estimated from a cost model.
Bansal reports the training loop is tractable on a single 8×H100 node — days, not weeks — and the resulting model runs inference in single-digit milliseconds. That last number is the one that matters if this ever leaves the lab: Postgres's own planner runs in microseconds to low milliseconds on typical OLTP queries, so QoRL is already in the same order of magnitude on latency, not off by 1000×.
Query optimization has been an open sore in relational databases since System R. The theoretical problem — pick the cheapest plan from an exponentially large search space — is NP-hard in the general case, and every production optimizer papers over that with a cost model that estimates how much work each candidate plan will do. The dirty secret of cost-based optimization is that cardinality estimation, the input to every cost calculation, is famously and persistently bad — errors of 10× to 1000× on multi-join queries are documented in every serious study going back to Leis et al.'s 2015 paper.
Classical optimizers compensate with heuristics, hints, and, in Postgres's case, a genetic algorithm (GEQO) that kicks in above 12 joins because the dynamic-programming enumerator gives up. None of this is elegant; all of it is load-bearing infrastructure in every production Postgres deployment on Earth.
ML-based optimizers have been circling this for years — Neo and Bao from MIT, Balsa from Berkeley, DeepMind's AlphaJoin. The blocker was always the same trade-off: models good enough to win required inference costs that dwarfed the query itself, and training required either a hand-built simulator or thousands of real query executions. Bao dodged this by learning a hint-picker on top of Postgres's existing plans rather than replacing the planner outright — a smart hedge, but a ceiling.
QoRL's contribution isn't a new algorithm. It's a demonstration that the frontier-lab recipe — mid-sized transformer, RL from a real reward, execution-time feedback — now works well enough at 4B parameters to matter for a system as latency-sensitive as a query planner. Postgres's optimizer isn't losing to a smarter algorithm; it's losing to a model that skipped the cost-model step entirely and learned directly from what actually runs fast.
The HN thread is worth reading for the skepticism, which is warranted. The benchmark set isn't TPC-DS. Training data comes from a specific schema and workload distribution; nothing in the post proves the model generalizes to a schema it hasn't seen. And 'produces a plan 81% faster' collapses a lot of variance — the median improvement and the tail behavior on adversarial queries are the numbers that would actually determine whether you'd trust this in production.
Nothing, this week. QoRL is not a Postgres extension you can `CREATE EXTENSION qorl;` into your database. It's a research prototype that emits plans your database can consume. The gap between that and something you'd point at a production replica is at least a year of engineering — schema-agnostic training, robust fallback when the model produces a plan the executor rejects, and a story for statistics drift.
But the direction is now clear enough to plan around. If you're building on top of Postgres and you have queries that survive on `pg_hint_plan` and hand-tuned `enable_nestloop = off` switches, you are running a small, brittle, human-in-the-loop version of what QoRL is trying to automate. The workaround exists because the optimizer is wrong in predictable ways; something that learns from those failures is the natural next thing.
For teams running large OLAP workloads on Postgres, Snowflake, or DuckDB — the analytical side, where join orders matter most and per-query planning cost is negligible against seconds-long execution — an ML optimizer sitting in front of the planner as a hint provider (the Bao pattern, but with a QoRL-scale model behind it) is a plausible six-to-twelve-month product. Watch the cloud databases for this before self-hosted Postgres; the training data lives in their telemetry, and the ROI on faster plans is directly monetizable.
The interesting question isn't whether Postgres itself will ship a neural optimizer — it won't, not soon, because the community's engineering values (deterministic, debuggable, portable) are the opposite of a trained model's. The question is whether the extension ecosystem or a fork like Aurora, Neon, or CockroachDB ships one first, and how long the classical optimizer stays competitive once someone does. The last time a full-model replacement of a hand-tuned system component looked implausible was compiler code generation five years ago. That one didn't age well either.
Engineer: "HELP, our production DB is frozen on this query that worked fine before!"Infra: "Hmm, let's check... Well would you look at that, it seems like your LLM query planner usually works and produces fast queries, but this time when you changed a variable name to trigger que
Optimal plan construction is math-heavy, algorithm-heavy and vary even by workload. There are options like creating just-in-time indexes, so solution space grows even faster than article presents. Sometimes it is the query planner which is the slow part of total execution time.LLM is kind of blunt w
> Frontier intelligence is extremely powerful; the distillation I did off Astra trajectories is proof enough that large models are not going anywhereWouldn't admitting this invite trouble due to accusations of distillation flying around between closed and open models.
The end game is adaptive query plans.A big reason the initial plan isn't guaranteed to be optimal, even with all the right indexes, is that table statistics aren't perfect. For example, you might track a column's correlation (how closely the column's logical ordering matches its
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
“81% faster query plans than Postgres”…on an 8 GB dataset that fits entirely in memory, with shared_buffers constrained to a fraction of that, queries warmed before measuring, and read-only SELECTs.I would be cautious about over fitting, it’s tough to say if those query plans would really be more op