The 300x Faster Postgres Isn't Postgres

Michael Malis just published the most instructive database performance writeup of the year, and the headline number is the least interesting thing in it. His project, pgrust, runs analytical queries hundreds of times faster than PostgreSQL. But pgrust isn't Postgres with better settings. It's a from-scratch Rust reimplementation of Postgres — written largely by AI coding agents over roughly three months — that speaks the Postgres wire protocol and passes all 46,066 tests in the Postgres regression suite. The "300x faster Postgres" framing buries both what's genuinely impressive here and what should make you keep it far away from production.

Where the 300x actually comes from

Malis's benchmark is deliberately friendly to vectorization — a single aggregate over 500 million floats:

CREATE TABLE my_table AS select col::float8 from generate_series(1.0, 500000000.0) g(col);
SELECT SUM(col) FROM my_table;

Postgres takes about 20 seconds. A naive Rust interpreter built on the same tuple-at-a-time Volcano model Postgres uses runs it in 1.3 seconds. Then the ladder: processing rows in batches of 1,024 instead of one at a time drops it to 480ms, fusing the scan and aggregate operators into one loop gets to 358ms — matching a hand-written Rust for-loop — and hand-rolled ARM NEON intrinsics, eight doubles per iteration across four accumulator vectors, land at 135ms. At that point you're pushing several gigabytes per second per core and the bottleneck is memory bandwidth, which is exactly where an analytics engine should die.

Malis is upfront that this isn't apples-to-apples — Postgres is also paying for locking and tuple deforming that his loop skips — and that the fused operator is hardcoded for this query shape (the general version needs JIT compilation, which pgrust does and he's promised to write up separately). He credits the query engine with roughly 10x of pgrust's overall gap against Postgres on ClickBench; the rest is mostly columnar storage, which is where every OLAP engine earns its biggest multiplier by reading only the columns a query touches.

You've read this paper before

None of these techniques is new. Batched execution is the MonetDB/X100 paper from CIDR 2005. Operator fusion via query compilation is Thomas Neumann's HyPer paper from VLDB 2011. SIMD-heavy columnar scans are the daily bread of ClickHouse, DuckDB, Velox, and DataFusion. As a tutorial on why modern OLAP engines embarrass row stores, the writeup is excellent. As research, it's a two-decade-old reading list, competently executed.

What is new is who executed it and what it cost. By Malis's own accounting, pgrust took four attempts and about $100,000 in agent spend: a feature-by-feature port with Codex agents that stalled at 96% of the regression suite, a c2rust mechanical transpilation that passed everything but produced millions of lines of unmaintainable unsafe Rust, an idiomatic crate-by-crate rewrite that drowned in type-definition drift, and a final attempt — Claude and Codex agents with access to all the prior codebases — that produced roughly 1.8 million lines of idiomatic Rust and a fully green test suite. The v0.2 release claims a ClickBench combined score 18.5% ahead of ClickHouse on an AWS Graviton4 box, alongside modest OLTP gains over Postgres 18.3.

Why Postgres core can't just do this

The uncomfortable subtext is that Postgres knows all of this and still can't ship it. The Volcano executor, per-tuple function dispatch, and the row-oriented heap aren't oversights; they're load-bearing walls that thirty years of extensions, FDWs, and index access methods are bolted into. Postgres did add LLVM-based JIT in version 11, but it compiles expression evaluation and tuple deforming inside the same one-row-at-a-time loop — it never got the 10x because the 10x requires changing the executor's contract, and vectorized-executor proposals have been bouncing off pgsql-hackers for years.

That's why the real "fast analytics without leaving Postgres" market is served by things that graft a foreign engine onto the elephant: pg_duckdb embedding DuckDB's vectorized executor, Citus and Timescale's columnar formats, AlloyDB's columnar engine, or CDC pipelines into ClickHouse. If you have a Postgres instance groaning under aggregation queries today, those are your actual options, in roughly that order of adoption effort. pgrust is not on the list.

The asterisks

Ruohang Feng — Pigsty's founder and no Postgres tourist — published the sharpest critique, arguing pgrust is less a rewrite than "code laundering": the passing version descends from mechanically translated Postgres C, not a clean-room design, and the public test runner executes serially with fsync disabled. The ClickBench numbers are self-reported from the project's own hardware, not an independent leaderboard entry. And a green regression suite proves output compatibility on known cases; it says nothing about crash recovery, concurrency under adversarial load, or the thousand edge cases Postgres fixed between 1996 and now that never got a test. Malis, to his credit, agrees on the conclusion — the README says plainly that pgrust is not production ready and you shouldn't put data you care about in it. There's also no extension ABI, so none of Postgres's 1,600-plus extensions work, and the AGPL-3.0 license will stop plenty of companies at the door regardless.

Weigh the critique fairly, though: the four-attempts writeup discloses the c2rust lineage openly, and "AI agents translated and restructured one of the most battle-hardened C codebases into working, test-passing Rust" is a real result even if "rewrote" oversells it.

What to take from it

Don't deploy pgrust. Do read it as an existence proof with a price tag. The expensive part of database engineering was never the vectorized sum loop — it's the decades of hardening — but the code half of the moat just repriced from person-centuries to a hundred grand and a summer. Every incumbent whose defense is "nobody will ever reimplement this" should update. Postgres's actual moat — trust, governance, the extension ecosystem — is intact, and pgrust's fastest path to mattering is probably as a pressure campaign: a running demonstration of what the executor could be, the way ClickBench itself shamed a generation of row stores into columnar side-engines.

And if you write data-plane code for a living, the microbenchmark ladder is the takeaway you can use this week: batch your inner loops, fuse your passes, and give the compiler a flat array to chew on. That 10x doesn't require rewriting a database. It barely requires an afternoon.