pgrust, an AI-Built Rust Rewrite of Postgres, Passes Every Regression Test

A ground-up Postgres rewrite in Rust, built largely by AI coding agents, now passes 100% of PostgreSQL's regression and isolation test suites — a milestone its own creator is careful to frame as a starting point, not a finish line.

A Ten-Week Sprint From One-Third to a Full Regression-Test Pass

The project, called pgrust, began in April 2026 as a solo effort by Michael Malis, a former Postgres administrator at the analytics company Heap and later CEO of Freshpaint. In his original write-up, Malis described starting the rewrite from scratch rather than trying to port Postgres's tightly coupled C codebase piece by piece, using AI coding agents — primarily OpenAI's Codex — to build out core subsystems like the storage layer, query executor, and concurrency controls. Two weeks in, the codebase had reached 250,000 lines of Rust and was passing roughly one-third of Postgres's regression suite, which he described as containing about 50,000 SQL test queries.

Progress accelerated from there rather than slowing down, which Malis said surprised him. A week-eight update put the pass rate at 67%, the codebase past 450,000 lines, and described running up to 20 parallel AI coding sessions across eight separate Codex subscriptions to work around per-account rate limits. By early May, a follow-up post put compatibility at 96%. A June 25 post confirmed the project had reached a full pass of both the regression suite and Postgres's separate isolation tests, and disclosed that Malis has since been working on pgrust alongside a collaborator, Jason Seibel.

The Vacuum, Connections, and Query-Planning Problems pgrust Was Built to Fix

pgrust isn't framed as a like-for-like port. Malis's stated goal is to use the rewrite as a testbed for architectural changes he considers difficult or politically stalled inside mainline Postgres. His clearest explanation of that reasoning outlines four recurring sources of Postgres outages he's targeting directly.

The first is vacuum-related transaction ID wraparound. Because Postgres marks deleted rows rather than removing them immediately, and tracks transactions with a 32-bit ID space, a vacuum process that falls behind can force Postgres to shut a database down entirely to prevent ID reuse and data corruption — something Malis said he believes has caused thousands of Postgres outages. pgrust is exploring both a 64-bit transaction ID scheme and an alternative, vacuum-free deletion architecture similar to Oracle's undo-log approach, though neither has shipped yet.

The second is Postgres's process-per-connection model, which caps concurrent connections and makes query parallelism expensive because spinning up a new OS process is costly. This suggests why pgrust was designed from the outset around a thread-per-connection model instead — a change Malis argues is only safe because Rust's compile-time memory guarantees remove the isolation risk that originally pushed Postgres toward processes over threads.

The remaining two — brittle query planning with no tuning mechanism when Postgres chooses a bad execution plan, and the absence of real statistics for JSON/JSONB columns — remain further out on the roadmap; Malis described an adaptive query planner and JSON statistics support as goals rather than completed work.

What Passing Every Regression Test Does — and Doesn't — Prove

According to the project's own summary, pgrust now targets compatibility with Postgres 18.3, passes the standard regression and isolation test suites, and can boot directly from an existing Postgres 18.3 data directory. The same post states plainly that it is not production-ready, not yet performance-optimized, and not compatible with existing C-based Postgres extensions.

That gap between "passes the tests" and "ready for production" was the central thread in reader discussion after the milestone was posted to Hacker News. Commenters pointed out that Postgres's regression suite encodes decades of previously discovered bugs — meaning a full pass demonstrates the rewrite doesn't repeat known failure modes, not that it's free of new ones a from-scratch codebase could introduce. Others raised the AGPL-3.0 license as a departure from Postgres's permissive licensing, and questioned whether pgrust's bundled extensions cover enough of the existing ecosystem to matter for real deployments; one reply noted that most existing Postgres extensions would need to be rewritten rather than ported.

Malis has previously acknowledged this distinction directly: in the 67% update, he wrote that synthetic test suites can pass while subtle correctness or durability issues persist under real workloads, and said the project's next priority after full compatibility is stability testing against real, low-stakes workloads — replicas of hobby projects and internal tools — rather than synthetic benchmarks alone. No independent performance or reliability benchmarking of pgrust has been published by a third party as of this writing, and Postgres's own decades of production hardening remain the standard pgrust has not yet had time to accumulate.