Postgres has been rewritten in Rust, and the project known as pgrust just passed 100% of Postgres's 46,000+ regression test suite against Postgres 18.3. This is a rewrite that stays fully compatible with Postgres at the disk and protocol level, meaning it can boot from an existing Postgres data directory and speak the same wire protocol. The project, by Michael Malis (formerly CEO of Freshpaint and a Postgres veteran who ran petabyte-scale clusters at Heap), has reached this milestone in roughly 12 weeks using an aggressive AI-assisted development pipeline.

Background

Pgrust is not a fork. It is a ground-up reimplementation of Postgres in Rust that matches the expected output of every query in the Postgres 18.3 regression suite. The codebase weighs in at around 98 MB of Rust, plus vendored Postgres test files. It ships with a Docker image, a WebAssembly demo you can run in your browser at pgrust.com, and full documentation for building from source on macOS and Linux.

The project started as an experiment. Malis wanted to see whether modern AI coding agents (primarily OpenAI's Codex and GPT-5.5 running through Conductor) could accelerate the kind of deep systems programming that a database rewrite demands. The answer, as the 100% test pass rate demonstrates, is a resounding yes.

Why This Matters to Developers

Postgres is one of the most trusted pieces of infrastructure in the software industry. It has been developed over nearly 40 years and consists of roughly one million lines of C code. Rewriting it is a monumental task that few would attempt, let alone pull off.

What makes pgrust significant is not just that it works, but what it enables:

Multithreaded internals. Postgres uses a process-per-connection model for historical reasons. Moving to threads could unlock significant performance gains. In early benchmarks, Malis found thread-based parallelism delivered up to 3x faster queries on small in-memory datasets compared to Postgres's process-based approach.

Built-in connection pooling. Every Postgres deployment needs a separate connection pooler like PgBouncer. Pgrust's roadmap includes native pooling, removing one of the most common operational pain points.

No-vacuum storage designs. Vacuum is a recurring source of production outages. The pgrust roadmap experiments with storage engines that eliminate vacuum entirely.

Runtime guardrails for AI-generated SQL. As AI coding agents write more database queries, pgrust plans to add guardrails that catch bad query plans before they impact production.

Technical Breakdown

How It Works

Pgrust targets Postgres 18.3 and is tested against more than 46,000 regression queries that ship with Postgres itself. It uses the same SQL parser output, the same query plans, and the same on-disk format. You can point pgrust at an existing Postgres data directory and it will boot with your existing data intact.

The AI-Assisted Pipeline

The most remarkable aspect of pgrust is the development process. Malis ran between 10 and 20 concurrent Codex sessions through Conductor, each working on a separate feature in its own git worktree. He maintained 8 Codex subscriptions to work around rate limits.

At first, agents worked on large features independently. But merge conflicts became a bottleneck. The team shifted to smaller, testable increments that each agent could complete and merge quickly. This approach, combined with CI workflows, kept velocity high even as the codebase grew past 450,000 lines.

Performance Findings

Early benchmarks reveal two areas where pgrust already outperforms Postgres:

1. Thread-based parallelism. Postgres parallelizes queries across processes, which adds overhead. Pgrust's thread-based model eliminates that overhead, showing up to 3x speedups on parallel queries.

2. Rust regex engine. Postgres's regex engine predates modern regex syntax. The Rust regex crate uses SIMD instructions and is up to 10x faster on pattern-matching workloads.

These are early results on unoptimized code. Malis emphasizes that the current priority is correctness, not performance. But the headroom is real.

Practical Example: Running Pgrust

You can try pgrust right now, either in the browser at pgrust.com or via Docker:

Then connect with any Postgres client:

The WebAssembly demo is preloaded with examples showing window functions, JSONB queries, foreign keys, EXPLAIN ANALYZE, regex matching, and even a recursive-CTE Lisp interpreter running inside the database.

What Is Not Ready Yet

Pgrust is not production-ready. The README is explicit: it is not performance optimized, and most existing Postgres extensions and procedural languages (PL/Python, PL/Perl, PL/Tcl) are not yet compatible. Some bundled contrib modules have been ported, but the extension ecosystem will need significant work.

Compatibility means "this query returns the right answer." Production-readiness means "this query returns the right answer for the next 90 days under load." Malis is actively seeking hobby projects and side workloads to test pgrust as a replica, precisely to close that gap.

Frequently Asked Questions

Is pgrust a drop-in replacement for Postgres? Yes, at the protocol and disk level. You can swap a Postgres data directory into pgrust. However, extensions and PL languages are not yet compatible.

Can I use pgrust in production today? No. It is an early-stage project with known correctness and performance gaps. Use it for experimentation and development only.

Why AGPL license? The project uses AGPL-3.0. This is a departure from Postgres's permissive license, but Malis has indicated it is about protecting the open-source investment while enabling commercial use for those who need different terms.

Does pgrust support JSONB? Yes. JSONB support was one of the early features ported, along with window functions, PL/pgSQL, foreign keys, and full-text search.

How does this compare to other database rewrites? It follows the path of projects like libSQL (SQLite rewritten in Rust, now Turso). The key difference is pgrust maintains wire compatibility with the original, making migration far easier.

Will the Postgres community adopt this? The long-term question. If pgrust proves stable and faster, there is precedent for community adoption. But the AGPL license and the rewritten extension layer are significant barriers.

Key Takeaways

• Pgrust passes 100% of Postgres 18.3 regression tests with a ground-up Rust implementation
• The project was built in roughly 12 weeks using AI-assisted development with 10-20 parallel coding agents
• Early benchmarks show potential for significant performance improvements over Postgres in specific areas
• The roadmap includes multithreaded internals, built-in connection pooling, and AI-generated SQL guardrails
• Pgrust is not production-ready yet but is available for experimentation and testing

Conclusion

Pgrust represents a fascinating convergence of three trends: the push toward memory-safe systems programming (Rust), the increasing capability of AI coding agents, and the desire to modernize entrenched infrastructure. Whether or not pgrust itself becomes the next generation of Postgres, it has already demonstrated that rewriting complex systems software is no longer a multi-year endeavor. With the right AI-assisted workflow, it can happen in weeks.

The database landscape is changing. Pgrust is one of the most exciting signals of where it is heading.

---

Source: pgrust GitHub Repository, pgrust.com, malisper.me - pgrust launch post, HN Discussion