pgrust: A Full Postgres Rewrite in Rust, Tested

Postgres has roughly a million lines of C and nearly four decades of accumulated architecture. Someone decided to rewrite all of it in Rust. Then, somehow, the result passed all 46,066 official PostgreSQL regression queries.

That's the headline. Now let's talk about what it actually means.

The project is called pgrust, built by Michael Malis and Jason Seebol. The Better Stack team ran it through its paces—standard Docker image, unmodified psql client, real SQL queries, EXPLAIN output, 100,000-row inserts—and from the outside, as they put it, it was "completely indistinguishable from Postgres. Same client, same SQL, same output." The wire protocol is real. The query planner is real. The storage engine reads an existing Postgres 18.3 data directory without modification. Whatever pgrust is, it's not a demo or a toy. It's a functioning database server written in a different language.

That's genuinely unusual. The phrase "Postgres compatible" appears on a lot of project pages and means almost nothing—anywhere from "we support SELECT and INSERT" to "we implement most of the SQL standard." CockroachDB calls itself Postgres compatible. Yugabyte calls itself Postgres compatible. Both are distributed systems whose primary design goals sit elsewhere. pgrust takes actual Postgres behavior as its specification and uses the official regression test suite as its judge. Passing 46,066 of those queries is a measurable claim, not a marketing one.

So: respect where respect is due.

What pgrust Is Actually Trying to Do

Understanding why pgrust exists requires a quick look at what Postgres's architecture costs you. Every client connection in Postgres gets its own operating system process. That isolation is a feature—if one process crashes, the others keep running. But it comes with overhead: memory per connection, constant pressure toward external connection poolers like PgBouncer, and difficulty sharing state efficiently across parallel operations.

Rust's memory safety model makes a different trade-off possible. The unpublished development version of pgrust reportedly replaces the process-per-connection model with a thread-per-connection model. Threads inside the same process share memory more easily and carry less per-connection overhead. The Better Stack coverage flags the honest trade-off here: "Separate processes also create useful walls between connections. If one process fails, that separation can help contain the damage. With threads, one unsafe extension or memory bug could affect more of the server."

Thread-per-connection is not a novel idea—MySQL uses it, and there's a long debate in database engineering about which model serves better under which workload. What's novel is attempting it inside something that behaves, at the protocol and SQL level, exactly like Postgres.

The performance claims attached to this architectural shift are substantial. The developers report roughly 50% better performance on transactional workloads and approximately 300 times Postgres performance on analytical workloads. Those numbers are striking enough to warrant the obvious question: where's the code?

It's not available for inspection yet. The thread-per-connection version is unpublished. The current release, the one that passes the regression tests, is not heavily optimized and is not where those benchmark figures come from. Better Stack puts it plainly: "We don't have real stats just yet. That does not automatically mean the numbers are false, though. It just means we should treat them as promising claims, not settled facts."

That's the right frame. The 300x figure in particular should be held loosely until it can be reproduced independently. Analytical workload performance is highly sensitive to benchmark design—what data, what queries, what hardware, what configuration. A 300x improvement that evaporates under realistic conditions is a marketing number; one that holds up under scrutiny is a technical achievement. We don't know which this is yet.

The AI Angle Is the More Interesting Story

Buried underneath the benchmarks is a question that matters more in the long run: how did two developers rewrite a million-line codebase at all?

The answer is coding agents. Malis and Seebol used AI tools heavily throughout the rewrite. The published version of pgrust deliberately mirrors the original Postgres structure in many places—the architectural innovation is being saved for later. The AI was used to generate code quickly enough that a project of this scale became tractable for a small team.

That shifts the frame entirely. The question isn't just "can Rust make Postgres faster?" It's closer to what Better Stack articulates: "Can AI make a rewrite this large affordable enough that developers can actually rethink architecture underneath things?" If the answer is yes, then pgrust—regardless of whether it ever runs in production—is evidence that the cost curve for large infrastructure experiments has changed. Projects that previously required years of engineering time and significant organizational commitment might now be exploratory. That's a meaningful shift in what's possible.

There's a reasonable skepticism here too. Generating hundreds of thousands of lines of code quickly is not the same as generating correct, maintainable, production-hardened code. The Hacker News discussion around pgrust ran to hundreds of comments and points, with a split between people impressed by the regression test achievement and people pointing out that tests don't replicate years of crash recovery, replication edge cases, and the kind of bugs that only surface after a database has been running continuously for months. Both reactions are correct. They're addressing different questions.

The Extension Problem

One gap worth naming explicitly: extensions. Postgres's extension ecosystem—PostGIS, pgvector, TimescaleDB, and hundreds of others—is a significant part of why organizations choose Postgres in the first place. Extensions hook into Postgres internals. A complete rewrite doesn't inherit that ecosystem automatically; it has to rebuild compatibility for each one, or provide a shim layer, or tell users to go without.

pgrust hasn't solved this. The Better Stack coverage notes that extension compatibility remains a major unfinished area. For many production deployments, this is the actual blocker, not benchmark numbers or thread models. A database that runs 50% faster but can't run PostGIS is a harder sell to the teams that need PostGIS.

This is solvable in principle. It's not solved yet.

Where This Sits Right Now

pgrust is an experimental project that has cleared a meaningful technical bar. It is not production software, and its developers say so. You should not migrate your production database to it. The extension ecosystem is incomplete. The most interesting architectural version—the one with thread-per-connection and the extraordinary performance claims—hasn't shipped publicly.

What it is: a demonstration that the official Postgres regression suite can serve as a specification rigorous enough to build against, that AI tooling has changed the labor economics of large rewrites, and that there's genuine engineering interest in questioning assumptions baked into Postgres's architecture in the 1990s.

Whether pgrust specifically becomes important is an open question. What seems harder to dismiss is the possibility it represents: that the era of "we can't afford to rethink this" may be ending—one benchmark at a time, once someone actually publishes the code.

Bob Reynolds is Senior Technology Correspondent at BuzzRAG.