pgrust Passes 100% of Postgres Regression Tests: What the Rust Rewrite Actually Means

Last updated: July 9, 2026

A GitHub project called pgrust hit the Hacker News front page today with a headline that turned heads: a complete PostgreSQL reimplementation in Rust, passing 100% of Postgres's regression tests. The post pulled 184 points and 236 comments in a few hours, and the discussion quickly split into camps - some excited about memory safety in the database layer, others skeptical about what "passing tests" actually proves.

The project comes at an interesting moment. AI-assisted rewrites are suddenly feasible, and the Rust-rewrite-of-everything trend has moved from coreutils to major infrastructure. But rewriting Postgres is a different beast entirely. Let me break down what pgrust actually is, what the HN crowd thinks about it, and the harder questions that emerge.

What pgrust actually claims

According to the project README, pgrust targets compatibility with Postgres 18.3. The implementation runs over 46,000 queries from the Postgres regression suite and produces output that matches the expected results.

Key technical details from the repository:

• 99.8% Rust codebase with vendored Postgres 18.3 source as reference
• Disk-compatible with existing Postgres 18.3 data directories - you can point it at your existing data
• Not production-ready - the author explicitly says performance optimization has not been a focus
• AGPL-3.0 license - a notable choice given Postgres itself uses the permissive PostgreSQL license
• WebAssembly demo available at pgrust.com for browser-based testing
• Extensions not supported - PL/Python, PL/Perl, and PL/Tcl do not work; some contrib modules have been ported

The stated goal is revealing: "make Postgres easier to change from the inside: keep the behavior Postgres-shaped, keep the real Postgres tests as the oracle, and use Rust plus AI-assisted programming to explore deeper server changes."

This is not a production database replacement. It is an experimentation platform that happens to pass the compatibility tests.

What HN is saying

The Hacker News discussion surfaced several recurring themes that cut to the heart of what these AI-assisted rewrites mean.

The "tests are not production" argument came up immediately. As one commenter put it: "the things that make software like Postgres and SQLite reliable are not mostly the test, but the real world production scars. That's where the reliability comes from, years and years of running in production."

This is a fair point. Postgres has been running in production since 1996. Every obscure edge case, every race condition, every corrupt-data-recovery scenario has been encountered and patched. A rewrite that passes regression tests has not faced any of that.

The AGPL license choice drew attention. Postgres's permissive license is part of why it won - companies can embed it without viral licensing concerns. pgrust choosing AGPL means any company that runs it and modifies it would need to open-source those modifications. One commenter noted that "Postgres has shown an open source SQL server didn't need a copy-left license to develop sustainably."

The "why should I use this" question appeared multiple times. Without extension support, without performance optimization, without production battle-testing, the practical use cases are narrow. The honest answer from the project seems to be: you probably should not use it for anything real. It is a research vehicle.

The AI-assisted rewrite skepticism was palpable. Several commenters distinguished between "a rewrite" and "an AI rewrite," suggesting the latter carries less engineering ownership. One commenter bluntly called these projects "software talibans" - an overstatement, but it reflects real fatigue with Rust-rewrites-of-everything that never gain adoption.

But some saw value regardless. "I find these projects interesting for learning purposes and exploring new ways. What's wrong with that?" And the comparison to Bun came up - Jarred Sumner successfully rewrote Node's internals in Zig with real performance wins. Could pgrust evolve similarly?

The deeper questions

The HN discussion touched on something important that I want to pull out explicitly: what does it mean when AI can produce a code-compatible rewrite that passes all tests?

First, tests are a floor, not a ceiling. Passing 100% of regression tests proves behavioral compatibility for documented scenarios. It does not prove correctness in undocumented edge cases, race conditions, crash recovery, or performance characteristics. Postgres's reliability comes from decades of production incidents that taught the maintainers what to test for - and what cannot be tested easily.

Second, the question of maintenance. pgrust is a snapshot. Postgres releases updates constantly. Who maintains parity? The AI can regenerate code, but understanding why Postgres made a particular change requires human context.

Third, the experiment value is real. The project explicitly lists planned experiments: multithreaded internals, built-in connection pooling, no-vacuum storage designs, runtime guardrails for bad queries. None of these are easy to prototype in the real Postgres codebase. A Rust clone with passing tests gives you a sandbox to explore architectural alternatives without breaking production.

This is the most compelling interpretation of pgrust: not as a replacement, but as a clean-room for ideas that would be too risky to develop against the real codebase.

Should you care?

If you run Postgres in production, this changes nothing today. Continue using the real thing.

If you are researching database internals, pgrust might be a more approachable codebase than 30 years of C. Rust's type system and memory safety guarantees make certain kinds of experimentation safer.

If you are evaluating AI-assisted code generation, this is an interesting data point. A 1.3 million line codebase can be translated to another language with test compatibility preserved. That says something about the tractability of mechanical translation - even if it says nothing about the harder problems of performance, reliability, and evolution.

The honest take: pgrust is impressive engineering, but the "100% tests passing" headline oversells what that means. The real Postgres is not its test suite - it is the community, the production scars, the extension ecosystem, and the 30-year track record. Those cannot be rewritten in Rust.

Sources

• pgrust GitHub repository - full project code and README
• Hacker News discussion - 236 comments as of this writing
• PostgreSQL official site - for context on the original project