pgrust: Rewriting Postgres in Rust — 100% Regression Tests Passing

A Bold Engineering Experiment

In the database world, PostgreSQL stands as an enduring giant. Born out of the POSTGRES project at UC Berkeley in 1986 — led by Turing Award winner Michael Stonebraker — it officially adopted SQL support and was renamed PostgreSQL in 1996. Notably, POSTGRES itself grew out of the earlier INGRES project, introducing object-oriented database concepts and an extensible type system. This "extensibility-first" design philosophy has guided PostgreSQL's evolution ever since. Architecturally, PostgreSQL uses a multi-process model — each client connection gets its own dedicated backend process — in sharp contrast to MySQL's multi-threaded approach. This provides stronger fault isolation, but also makes connection pooling tools like pgBouncer a standard requirement in high-concurrency deployments. After nearly 40 years of iteration, PostgreSQL is renowned for strict ACID transactions, rich data types (JSON, arrays, custom types), and a powerful extension ecosystem. It consistently ranks among the top open-source relational databases on DB-Engines and is widely adopted by tech giants including Apple, Instagram, and Spotify.

Recently, an open-source project called pgrust went viral on GitHub, gaining 789 stars in a single day and surpassing 2,000 total stars. Its goal sounds almost audacious: a complete rewrite of Postgres in Rust.

Even more striking is the project's claim to have passed 100% of Postgres regression tests. For anyone familiar with the complexity of database development, this result demands serious attention — this isn't a toy demo, but a systematic attempt to reconstruct mature, industrial-grade software.

Why Rewrite Postgres in Rust?

The Historical Baggage of C

Postgres's core codebase is written in C — performant beyond question, but inherently prone to the classic pitfalls of C: manual memory management, buffer overflow risks, and null pointer dereferences. This isn't unique to Postgres. Security research from both Microsoft and Google has found that roughly 70% of critical security vulnerabilities stem from memory safety issues. In 2023, CISA (the U.S. Cybersecurity and Infrastructure Security Agency) published a report explicitly recommending that new projects prioritize memory-safe languages.

As the infrastructure underpinning critical business data, any memory safety vulnerability in a database can have catastrophic consequences. PostgreSQL's CVE history includes notable examples — such as the buffer overflow CVE-2018-10915 — issues that Rust's ownership model would fundamentally prevent.

Rust's Core Advantages

Rust has become a go-to choice for rewriting systems software precisely because it guarantees memory safety and thread safety at compile time, without a garbage collector. These guarantees stem from Rust's ownership system — not merely syntactic sugar, but a formal memory management model embedded in the type system, with theoretical roots in Linear Types and Region Inference.

Rust's memory safety is enforced by three compile-time rules: each value has exactly one owner; when the owner goes out of scope, the value is automatically freed; and you can have either multiple immutable references or exactly one mutable reference, but never both simultaneously. The borrow checker validates these rules statically at compile time via Non-Lexical Lifetimes (NLL), with memory layout and lifetimes fully determined at compile time. For highly concurrent systems like databases, Rust further distinguishes — at the type level via Send and Sync traits — which data structures can safely cross thread boundaries. In C, this relies entirely on documentation and code review, leaving significant room for subtle bugs. Key advantages include:

• Memory safety: The ownership model and borrow checker fundamentally eliminate a wide class of common memory errors.
• Zero-cost abstractions: High-level expressiveness with runtime performance comparable to C/C++.
• Concurrency safety: Compiler-enforced concurrency rules dramatically reduce data race risks — especially valuable for high-concurrency database systems.

From Rust's introduction into the Linux kernel to rewrites of Android system components and Windows drivers, Rust's penetration into systems programming has been relentless. pgrust is the natural extension of this trend into the database domain.

What Does Passing 100% of Regression Tests Actually Mean?

The Weight of the Test Suite

The Postgres regression test suite is the project's most compelling proof point. Located in src/test/regress in the source tree, it contains over 200 test scripts covering SQL standard compliance (SELECT, JOIN, subqueries, window functions), data types (numeric, string, temporal, geometric, JSON), stored procedures, triggers, transaction isolation levels, the permission system, and error handling. The test framework (pg_regress) uses a diff-based validation approach: actual output from each test script is compared line-by-line against .expected files in version control, and any deviation causes a failure. Built up over decades by the community — with every new feature required to include corresponding tests — this suite is PostgreSQL's core validation baseline and a mandatory gate for every release.

Passing 100% of regression tests means pgrust has achieved high functional alignment with the original Postgres at the behavioral level — the same SQL input produces the same output. This is a far higher bar than "it runs," and demonstrates substantial engineering investment in protocol compatibility and semantic correctness.

A Note of Caution

Passing regression tests is not the same as being production-ready. It's worth emphasizing that regression tests primarily validate functional correctness and output consistency — they do not cover concurrent race conditions, behavior under extreme load, or long-running stability. Those require dedicated stress testing (e.g., pgbench) and chaos engineering. Passing 100% of regression tests is a necessary condition, but far from sufficient. Real-world deployment requires considering:

• Performance: Whether the Rust implementation can match or exceed the C version's throughput and latency under real workloads still requires large-scale benchmarking.
• Ecosystem compatibility: Postgres has a vast extension ecosystem (PostGIS, pgvector, etc.) — whether C-written extensions can remain compatible is a significant challenge for the rewrite.
• Stability and operations: Decades of production-grade hardening cannot be reproduced in the short term.

Technical Considerations on the Rewrite Approach

Completely rewriting a mature database typically follows one of two paths: the "incremental" approach — using FFI (Foreign Function Interface) to gradually replace C modules — exemplified by the curl project's adoption of the hyper library, which retains the C framework while replacing modules one by one. Risk is manageable, but unsafe code at C/Rust boundaries still demands careful handling. The second approach is "ground-up reconstruction" — reimplementing the entire architecture in Rust, yielding the cleanest possible design, but requiring full re-validation and a deep understanding of tightly coupled subsystems like the query planner, executor, WAL, and MVCC. Based on pgrust's complete regression test results, it appears to have taken the latter path — and has done impressive work on protocol-level and execution-level compatibility.

Two subsystems deserve special mention for their core complexity: WAL (Write-Ahead Logging) and MVCC (Multi-Version Concurrency Control). WAL ensures the database can recover to a consistent state after a crash by replaying logs; its record format, checkpoint mechanism, and archiving strategy together form the foundation of PostgreSQL's replication and backup infrastructure. MVCC implements non-blocking reads by maintaining multiple versions of each record (marked by xmin/xmax transaction IDs) — reads see a consistent historical snapshot, writes create new versions, and a VACUUM process cleans up expired versions (dead tuples). Both subsystems are deeply coupled with the buffer pool manager, lock manager, and transaction log. They are the most likely sources of subtle bugs in a rewrite, and the core battleground where pgrust's technical credibility will need to be validated over time.

The extension ecosystem challenge deserves particular attention. PostgreSQL's extension ecosystem is one of its core competitive advantages — pgxn.org lists over 1,000 extensions covering geospatial (PostGIS), vector search (pgvector), time-series (TimescaleDB), and more. These extensions integrate deeply with the kernel through PostgreSQL's C extension API, and that API exposes direct memory layouts of many internal kernel structures (such as Node, PlanState, TupleTableSlot, etc.) — extension code accesses kernel data structures directly via pointers, rather than through a stable ABI boundary, meaning extensions must be compiled against the header files of a specific PostgreSQL major version. For pgrust to support existing C extensions, it would need to precisely replicate those struct memory layouts and provide a C-compatible dynamic library loading mechanism — essentially wrapping the Rust core in a C ABI emulation layer. The alternative is designing a native Rust extension interface, but that would require rewriting the entire extension ecosystem, which is not achievable in the short term. Compatibility with core extensions like PostGIS, pgvector, and TimescaleDB will directly determine whether pgrust can compete in real production environments — this is the biggest ecosystem obstacle on the path to production.

For the community, the true value of a project like this may not lie in "replacing Postgres," but in exploring a few key questions: Can Rust handle systems software engineering of this complexity? Given full compatibility constraints, how much stability and security benefit does a memory-safe rewrite actually deliver? The answers to these questions carry implications for the entire systems software industry.

Conclusion: An Experiment Worth Watching

pgrust currently has around 2,000 stars and 50 forks — still relatively early stage — but its growth trajectory and technical claims have already generated significant attention. It is both a showcase of Rust's ecosystem maturity and a compelling response to the question of whether classic software can be reconstructed in modern languages.

Regardless of whether it ultimately reaches production readiness, pgrust offers the community a valuable engineering reference: it validates the feasibility boundaries of Rust in large-scale systems software rewrites, exposes the deep ABI compatibility challenges between memory-safe languages and mature C ecosystems, and charts a technical path for future database kernel modernization efforts. For developers following databases, systems programming, and the Rust ecosystem, this is an open-source project worth tracking closely. Interested readers can visit its GitHub repository to explore its architecture and implementation in depth.

Key Takeaways