Postgres Rewritten in Rust Is Now Passing 100% of the Official Regression Tests

A project to rewrite PostgreSQL in Rust has hit a major milestone: it now passes every single test in the official PostgreSQL regression test suite. The project, called pgrust, lives on GitHub and represents one of the most ambitious system-level rewrites the Rust ecosystem has attempted. For anyone paying attention to how "rewrite it in Rust" has evolved from internet joke into legitimate engineering, this milestone feels genuinely significant.

What Is pgrust and Why Does It Matter?

The pgrust project is a complete reimplementation of PostgreSQL in Rust. It's not a wrapper around the existing C code—it's a ground-up rebuild that rethinks the database engine from scratch using a memory-safe, modern systems language. Passing PostgreSQL's official regression test suite proves, more convincingly than anything else could, that this Rust version behaves identically to the original.

PostgreSQL's regression tests aren't trivial. They cover everything: SQL parsing, query planning, transaction behavior, type coercion, date and time edge cases, interval math, indexing—thousands of discrete test scenarios. Passing all of them means pgrust produces identical results to the C reference implementation across an enormous surface area. That's genuinely difficult to achieve.

The "Rewrite It in Rust" Movement Reaches Database Infrastructure

We've seen high-profile Rust rewrites of foundational systems before: memory allocators, HTTP servers, DNS resolvers, parts of the Linux kernel. But databases are a different beast entirely. They manage persistent state, enforce ACID guarantees, handle multiple concurrent clients, and implement decades worth of SQL standards. The complexity is orders of magnitude higher than simpler tools.

Yet a PostgreSQL rewrite in Rust makes real sense. Rust's ownership model eliminates huge classes of memory safety bugs that plague C: buffer overflows, use-after-free errors, data races. The compiler catches these at build time. For something as critical as a database, these guarantees matter enormously.

PostgreSQL's C codebase is well-maintained and carefully engineered, yet manual memory management still introduces inherent risks. A fully compatible Rust version would offer identical behavior with memory safety built in at the language level.

What Passing the Regression Tests Actually Means

Let's be clear about what this actually demonstrates. The PostgreSQL regression tests validate that pgrust produces the right answers—they confirm a SQL query returns identical results whether run against pgrust or standard PostgreSQL. This is essential. It's also not enough for production use.

The regression tests leave important gaps:

• Performance — query throughput, latency under real load, and optimizer efficiency at scale need separate benchmarking work.

• Crash recovery and durability — Write-Ahead Logging semantics and safe recovery from unexpected shutdowns require independent testing.

• Extension compatibility — PostgreSQL's ecosystem (PostGIS, pg_vector, and countless others) depends on a stable C API. A Rust rewrite would need to replicate or replace this.

• Wire protocol edge cases — standard client connections might work fine for common operations, but obscure protocol scenarios demand validation beyond the standard test suite.

None of this diminishes what pgrust has accomplished. Hitting 100% on the regression tests is the foundation everything else rests on. It marks the shift from "cool experiment" to "serious project."

Technical Challenges in Reimplementing PostgreSQL

PostgreSQL's query executor uses tree structures processed through recursive descent—a pattern that fights against Rust's ownership model, since C trees typically connect through raw pointers with messy shared-ownership semantics.

PostgreSQL's type system compounds this: arrays, composite types, ranges, domains all use dynamic dispatch patterns that need careful translation into Rust traits. And the details matter. Date and timestamp behavior, timezone calculations, interval arithmetic—all must match the reference implementation exactly.

The fact that pgrust passes all regression tests suggests these thorny problems have been solved, at least at the correctness level the standard suite demands.

What Comes Next

The obvious questions loom: Will pgrust add performance benchmarks? Will it build out the full extension API? Can it recruit contributors from the PostgreSQL community?

History suggests moving from "test suite passes" to "production ready" is a long road. But now there's a concrete starting line. If you're watching where systems programming and databases intersect, pgrust is worth following.

The code is open at github.com/malisper/pgrust.