pgrust: Postgres Rewritten in Rust, Passing 100% of the Regression Tests — What That Actually Means

Introduction — The "Postgres Rewritten in Rust" Headline
Passing 46,000 Queries — Why This Milestone Is Real
What "100%" Does Not Prove
Performance Claims, and the Fact That AI Wrote the Code
Closing — The Engine and Everything Around It
References

Introduction — The "Postgres Rewritten in Rust" Headline

Malcolm Matis (GitHub malisper) released pgrust. The one-line description is simple — "A Postgres rewrite in Rust". The headline is stronger: it passes 100% of the Postgres regression tests. Trending on top of GeekNews and Hacker News, the news pulls two opposite reactions at once — "Postgres in Rust, finally?" and "who's putting a database written by AI in a few weeks into production?".

This piece tries to calm both. What did pgrust actually accomplish, and what does the sentence "passes 100% of the regression tests" mean — and, crucially, not mean? The facts first: pgrust targets compatibility with Postgres 18.3 and produces output matching Postgres across more than 46,000 regression queries. It is disk-compatible, so it boots directly from an existing 18.3 data directory. And the author says so himself — it is not production-ready, not performance-optimized, and not compatible with existing extensions.

Passing 46,000 Queries — Why This Milestone Is Real

Do not underrate the Postgres regression suite. Run by make check, this battery of tests is an asset honed over decades: it sweeps the parser, planner, executor, type system, built-in functions, and the countless edge cases wedged between them across more than 46,000 queries. The bar is not loose — output must match the expected results byte-for-byte. One number formatted differently, one error-message wording off, and it fails.

pgrust lines all of that up against Postgres 18.3, and reports passing the isolation tests that verify scheduled concurrency as well. On top of that sits disk compatibility. Booting from a real 18.3 data directory means it actually understands the on-disk page format and catalog layout — a signal that this is not a toy that mimics a subset of SQL.

Anyone who has reimplemented even a single SQL parser from scratch knows how long the tail of edge cases is. When the whole pipeline agrees with Postgres across 46,000 queries, it has reproduced behavior over an enormous surface area. This is a real milestone. Do not underrate it.

What "100%" Does Not Prove

The trouble is that people read that sentence as "can replace production Postgres." That misreads what the regression suite verifies. Regression tests are a compatibility oracle for mostly single-session, deterministic query behavior. They do not prove:

Durability and crash recovery. The suite does not kill -9 mid-write and verify WAL replay, torn-page recovery, or fsync semantics under power loss. On Hacker News the author himself called heap management and durability "something I eventually want to fix," noting he is looking at adopting OrioleDB for storage down the line.
MVCC under real concurrency. The isolation tests cover scripted schedules. The adversarial concurrency of real workloads, long-running transactions, and the interplay of vacuum and bloat live outside that.
The long tail. Extensions and procedural languages like PL/Python, PL/Perl, and PL/Tcl are not compatible yet (the author says so). Replication, logical decoding, FDWs, and the entire operational ecosystem are absent.

And the method matters. An AI loop that keeps fixing until the tests go green risks converging on special-casing to the test rather than general correctness. One HN commenter summarized their own experience: all the tests passed with flying colors, yet the rewrite itself was broken even on basic functionality. It is the old maxim — there is no such thing as a complete test suite. "100% passing" means "no known divergence on the tested queries," not "bug-free." And it is not only critics saying this — the author put the three warnings up front himself: not production-ready, not performance-optimized.

Performance Claims, and the Fact That AI Wrote the Code

The README makes performance claims too — 50% faster than Postgres on transaction workloads, and roughly 300x faster on analytical workloads (2x slower than ClickHouse). It sounds impressive, but it has to be read next to the fact that the same README says it is "not performance optimized yet." HN was skeptical of the methodology: was fsync left on when measuring, and the comparison against ClickHouse — column-oriented and SIMD-tuned over years — is apples-to-oranges to begin with. Treat these numbers as directional at best.

Even so, the idea of a rewrite in Rust is genuinely interesting. Memory safety comes along for free, and unlike Postgres's process-per-connection model, pgrust chooses a thread-per-connection model, opening room for parallelism. The author cited figures like 3x on individual queries and 10x on regex in narrow contexts.

How it was built is another crux. Per the author's own write-up, about 250,000 lines of Rust were generated in roughly two weeks, passing about a third of the regression suite at that point. He started with Codex for individual features, then scaled to as many as 17 coding agents running in parallel "before maxing out the CPU." In HN replies he described starting from a c2rust mechanical translation and then rewriting the unsafe code, parallelizing the porting with Claude given specialized skills. So "rewritten in Rust" is partly "translated, then rewritten" — remarkable for speed, but also a way of saying there is a lot of generated, unoptimized code in there.

The reason it is hard is clear: decades of Postgres edge cases, MVCC, the on-disk format, the extension ABI. The regression suite serves as the bar precisely because those edge cases are otherwise invisible.

Closing — The Engine and Everything Around It

To sum up: passing 100% of the regression tests is a genuinely impressive milestone, and an excellent research vehicle for the goal of "making Postgres easier to change from the inside." But it is not "drop-in production Postgres." The gap between the two is filled mostly with the unglamorous parts — durability, replication, backups, upgrades, operational tooling — and that gap is measured in years.

This is exactly where it connects to my CNPG failover measurement piece. Production Postgres is not just the query engine. It is replication and failover, backups, rolling upgrades, and the operator ecosystem that automates all of it. In that article I killed a real Postgres primary and measured a replica getting promoted in 23.1 seconds with zero data loss. That "scaffolding around the engine" is precisely what an engine only a few weeks old has not yet grown. pgrust wins on the language surface; production wins on survivability. Both are true.

So I root for pgrust while reading the headline as a headline. The experiment of rewriting Postgres in Rust is well worth watching — but the moment you read it as "now I can swap out production Postgres," you have skipped past the three lines of warning the author wrote himself.