pgrust: Someone Rewrote Postgres in Rust and It Passes Every Regression Test

A developer working alone rebuilt Postgres from scratch in Rust and, in under three months, got it to match PostgreSQL 18.3’s output across every query in the standard regression test suite, more than 46,000 of them, plus the isolation tests that check concurrent transaction behavior. It’s called pgrust, and the honest headline isn’t “Postgres is being replaced.” It’s “an AI-assisted rewrite of one of the most battle-tested C codebases in existence went from a third of tests passing to all of them in a matter of weeks.”

What pgrust actually is

pgrust is exactly what it sounds like: PostgreSQL reimplemented from the ground up in Rust, not a Rust wrapper around the existing C engine, not a piecemeal port of individual files. The project’s creator, writing as malisper, made a deliberate choice early on to start from nothing rather than try to gradually convert the existing 30-plus-year-old C codebase in place. Converting in place risks long stretches where the system doesn’t run at all. Starting fresh meant something executable existed from day one, even if it only handled a fraction of Postgres’s behavior.

The project now sits at roughly 250,000 lines of Rust and covers the major Postgres subsystems: the query parser, planner, executor, storage layer, and transaction handling, all reimplemented well enough to reproduce Postgres 18.3’s behavior on the full regression suite. That’s a meaningfully high bar. Postgres’s regression tests exist precisely to catch subtle behavioral drift, edge cases in type coercion, locking semantics, error messages, that a superficially similar reimplementation would get wrong.

Where the speed came from

The part worth paying attention to isn’t the Rust rewrite itself, people have taken swings at reimplementing Postgres before. It’s the timeline. The project went from a first working skeleton to 100% regression compatibility in a period the creator describes in weeks, not years, and credits AI coding agents, mainly Codex, as the reason. The workflow was consistent throughout: point the agent at the relevant piece of Postgres’s C source, have it explain what that component actually does, then build a minimal Rust equivalent and check it against the regression tests.

That’s a specific and fairly disciplined use of AI coding agents, closer to “AI as a reverse-engineering and translation accelerant against a known, testable target” than “AI writes a database from a prompt.” The project’s own progress updates track the climb: an early post titled the project sitting at 67% Postgres compatibility “and accelerating,” followed weeks later by a post announcing 100% of the regression suite passing. Postgres’s regression suite functioned as ground truth the whole way through, which is likely why the result holds up. Without that oracle, an AI-assisted rewrite of something this complex would have no reliable signal for whether it was drifting from correct behavior. Teams exploring AI agents for large, unfamiliar codebases should take the same lesson: the agent needs a testable target, not just a task description, or speed comes at the cost of correctness you won’t notice until production.

What it isn’t, and why that matters more than what it is

pgrust is not production-ready, and the project doesn’t pretend otherwise. Passing regression tests demonstrates behavioral compatibility on a known set of cases. It says nothing about performance under load, since the project explicitly hasn’t been optimized yet, and it says nothing about the years of accumulated edge-case hardening that comes from running a database in front of real, adversarial, unpredictable traffic. Postgres earned its reputation for reliability the slow way, through decades of production incidents that shaped the code. A reimplementation, however faithful to the test suite, hasn’t been through that yet.

The stated goal backs this up: the project isn’t trying to be a drop-in production replacement soon. It’s trying to make Postgres’s internals easier to safely modify, using Rust’s compiler guarantees as a substitute for some of the manual discipline the C codebase currently demands. The motivation the creator cites lines up with real, well-known Postgres pain points: over 350 tunable settings where a single misconfiguration can take the whole database down, vacuum-related issues that are a leading cause of Postgres outages in practice, and a query planner that occasionally makes choices that surprise experienced operators. Those are exactly the kinds of problems where “the compiler catches a class of bug before it ships” is a genuinely useful property to have, separate from any argument about which language is faster.

What this means if you run Postgres in production

Nothing changes for you today. Don’t migrate anything to pgrust, and don’t expect to for a long while, if ever, given how much production hardening separates “passes the regression suite” from “trustworthy with your data.” What’s worth internalizing instead is the pattern: a single developer, with the right test oracle and a disciplined workflow, used AI coding agents to compress a rewrite that would traditionally take a team years into a project measured in weeks. That’s relevant whether or not you ever touch pgrust, because it’s the same pattern showing up in database migration projects and legacy modernization work more broadly: the bottleneck used to be developer-hours to understand and reimplement unfamiliar code. That bottleneck is loosening, and the projects that benefit most are the ones with an existing, thorough test suite to check the AI-assisted work against.

If pgrust matures into something with real performance characteristics and a production track record, that’s a story worth revisiting. For now, it’s a genuinely impressive proof of concept, and a useful data point on how fast AI-assisted rewrites of complex systems can move when there’s a rigorous oracle to check them against.