By Two developers and seventeen AI coding agents just rewrote PostgreSQL in Rust and passed all 46,066 of its regression tests. Michael Malis and Jason Seibel hit 100% compatibility with Postgres 18.3’s test suite this week with pgrust — a milestone that would have taken a large team years to reach without AI assistance. The Hacker News thread that followed split the developer community neatly in two: those who think this changes everything, and those who think passing tests is the easy part.
What 46,066 Tests Actually Means
The Postgres regression suite is not a toy benchmark. It is the canonical oracle for PostgreSQL correctness — the same test suite that caught every bug Postgres’s core team has fixed over decades. pgrust now passes all of it: 46,066 queries returning byte-for-byte identical output to upstream Postgres 18.3. The project also passes Postgres’s isolation tests and is disk-compatible — it can boot from an existing Postgres 18.3 data directory without conversion.
This is a meaningful bar. Most Postgres-compatible databases stop at wire protocol compatibility. pgrust passes the actual query regression suite, not just “can clients connect.” The difference matters if you care about behavioral correctness rather than surface compatibility.
How You Build 250,000 Lines of Rust With AI
Malis ran the project with an approach that would have seemed reckless two years ago: point AI coding agents at Postgres’s C source code, have them explain how each subsystem works, then build a minimal Rust equivalent. At peak, he coordinated 17 concurrent Codex agents across 8 accounts at $200 per month each, using custom tooling to track quota. The project merged roughly 280 pull requests in two weeks. According to Malis’s own account of the build process, AI was “a massive accelerant” — he estimates he couldn’t have reached this point without it.
His background matters here. Malis built petabyte-scale Postgres systems at Neon, the serverless Postgres company Databricks acquired for roughly $1 billion last year. He knows where the bodies are buried in Postgres internals. The AI agents wrote the code; Malis knew what to ask them to write.
The Architectural Bet Behind pgrust
pgrust is not just a compatibility clone. The point is to produce a codebase that is actually changeable. Postgres’s 35-year-old C code is tightly coupled and runs a process-per-connection model — every client gets its own OS process. That made sense in 1989. Today it creates overhead for parallel workloads and forces connection pooling through separate tools like pgBouncer, a workaround for a core architectural limitation.
The pgrust roadmap targets thread-per-connection instead, along with built-in connection pooling, fast database branching (think git for your Postgres instance), better statistics for JSON-heavy query planning, and vacuum-free storage experiments. These are not incremental improvements — they are architectural rewrites that Postgres’s conservative core team would never ship in a single version. The fact that Rust enables safer experimentation in a codebase this size is exactly why Malis chose it.
What the Skeptics Get Right
The project’s codebase contains 2,664 unsafe {} blocks and 1,835 unsafe fn declarations. Critics on Hacker News pointed out that much of this is mechanical C-to-Rust translation — not idiomatic Rust that actually leverages the type system for safety. Whether MVCC is correct under adversarial conditions and whether the speed claims hold under real workloads remain open questions. pgrust is explicitly not production-ready, and Malis says so clearly.
The deeper criticism is harder to dismiss: databases earn reliability through decades of production scars. Every edge case Postgres handles gracefully today corresponds to a failure that broke someone’s data at some point. Regression tests only cover bugs that have already been found. If you have followed the Hacker News thread, you will find this argument made forcefully, with examples. It is a legitimate concern for anyone considering pgrust as a production dependency — which nobody should be doing yet.
Why the Milestone Still Matters
pgrust is not trying to replace Postgres tomorrow. It is trying to prove that the architecture can be different. If threading and built-in pooling and fast branching actually work at scale, the result could be a Postgres-compatible database that is both faster and easier to operate — built on a foundation that Postgres’s committee-driven process could never have assembled this quickly.
The broader signal is what this demonstrates about AI-assisted infrastructure engineering. Malis built 250,000 lines of database code — passing a 46,066-query correctness oracle — with two people and an API bill. For context, ByteIota covered Rust 1.97’s release just this week, and the language continues to gain ground in systems work precisely because projects like pgrust are proving it is tractable at this scale. Whether pgrust ships as a production database or stays as a research platform, it has already shown that AI agents can take on correctness-critical infrastructure seriously.
