Postgres Rewritten in Rust: pgrust Passes 100% Regression Tests

PostgreSQL has been the undisputed king of open-source databases for nearly a decade. Startups, enterprises, and everything in between have standardized on it. But underneath that crown lies a codebase written in C, developed over nearly 40 years, with over one million lines of code and more than 350 configuration parameters. It is, by any measure, one of the most complex pieces of software ever built.

Now, a project called pgrust is doing something that would have seemed impossible just a year ago: rewriting Postgres from scratch in Rust. And as of this week, it passes 100% of Postgres's regression test suite — over 46,000 queries — while being disk-compatible with existing Postgres 18.3 data directories.

What is pgrust?

pgrust is the brainchild of Michael Malisper, a developer who spent years running a petabyte-scale Postgres cluster at Heap and has written extensively about Postgres internals. Frustrated by the same problems that plague every Postgres operator — vacuum meltdowns, connection pooler requirements, poor JSONB statistics, and the sheer complexity of 350+ settings — he decided to rebuild the database from the ground up in Rust.

The project launched just weeks ago with an initial 250,000 lines of Rust code generated with heavy assistance from AI coding agents, primarily OpenAI's Codex. At launch, it passed about one-third of Postgres's 50,000 regression tests. Now, the latest version passes 100% of the regression suite, targets Postgres 18.3 compatibility, and can boot directly from an existing Postgres data directory.

Why Rust?

The choice of Rust is not accidental. Postgres was written in C largely for historical reasons, and many of its architectural decisions — like the process-per-connection model — stem from limitations of the era in which it was built. Rust offers several fundamental advantages:

• Memory safety without garbage collection — no more buffer overflows or use-after-free bugs
• A thread-per-connection model instead of process-per-connection, which is dramatically more efficient
• Modern tooling with cargo, strong type checking, and a world-class package ecosystem
• Built-in connection pooling, eliminating the need for PgBouncer or external poolers
• Better JSON-heavy workload support with Rust's high-performance serialization libraries

The Performance Claims Are Wild

According to the project's latest updates, the new version of pgrust (not yet publicly released) is:

• 50% faster than Postgres on transactional workloads
• Approximately 300x faster than Postgres on analytical workloads
• Only 2x slower than ClickHouse on ClickBench — and they believe it can get faster than ClickHouse

Let that sink in. A Postgres-compatible database that approaches ClickHouse performance on analytical queries while maintaining full SQL compatibility. If these numbers hold up under independent benchmarking, it would represent a fundamental shift in what a single database can do.

The performance gains come from several architectural decisions that are only possible with a clean-slate rewrite. The thread-based model eliminates the overhead of process spawning. Rust's regular expression engine, which uses SIMD instructions, dramatically outperforms Postgres's legacy regex engine. And the ability to redesign internal subsystems without decades of technical debt means optimizations that would be impossible in the existing C codebase.

Built With AI in Weeks, Not Years

Perhaps the most remarkable aspect of pgrust is how it was built. Malisper credits AI coding agents — primarily Codex — as the primary accelerant. He explicitly states that this project would not have been possible two years ago, or even six months ago. The workflow involved pointing Codex at the Postgres source code, having it explain how each component worked, and then collaboratively building a Rust version.

On day one, working with Codex, he had a system that could run real SQL queries in about three hours. By the end of day one, it supported CREATE TABLE, SELECT, INSERT, UPDATE, DELETE, JOINs, transactions, and more. That trajectory — from zero to functional SQL engine in a single afternoon — is a testament to how AI coding tools are compressing development timelines for complex systems software.

This is a preview of what AI-assisted development looks like at the frontier. We are not talking about generating boilerplate or writing CRUD apps. This is rewriting one of the most complex software systems ever created — a 40-year-old database engine — and achieving compatibility in weeks rather than years.

What This Means for the Database World

pgrust is not production-ready yet. The project explicitly states this. But the implications are enormous, and they extend in several directions:

• For Postgres operators: A compatible rewrite could eliminate the most common operational pain points — vacuum tuning, connection pooler management, and configuration complexity — while maintaining the SQL interface and extension ecosystem they rely on.
• For the Rust ecosystem: This is the most ambitious Rust systems project to date, and it demonstrates that Rust can handle the most demanding workloads in the database space.
• For AI-assisted development: If AI coding agents can accelerate the rewrite of Postgres, they can accelerate the rewrite of virtually any complex system. The implications for software development velocity are profound.
• For the database market: A Postgres-compatible engine that approaches ClickHouse on analytics while maintaining OLTP capabilities could collapse the operational/analytical divide that has driven the HTAP market for years.

The Road Ahead

The pgrust roadmap is ambitious. Beyond the compatibility milestone, the project is targeting several Postgres pain points that have been discussed for years but never implemented due to the complexity of refactoring the C codebase:

• No-vacuum storage designs that eliminate the infamous vacuum problem entirely
• Runtime guardrails for bad queries and AI-generated SQL — increasingly important as natural language interfaces to databases proliferate
• Fewer sudden bad plan switches, addressing one of the most frustrating operational issues in Postgres
• Better support for forking and branching workflows, similar to what DuckDB offers

The project is AGPL-3.0 licensed, with a Discord community and regular updates being published. There is a WebAssembly demo available at pgrust.com where you can try it directly in your browser, preloaded with examples including a Lisp interpreter running inside the database.

A Glimpse of the Future

pgrust represents something larger than a database rewrite. It is a proof of concept for two converging trends: the maturation of Rust as a systems programming language capable of replacing C in the most demanding domains, and the emergence of AI coding agents as tools that can accelerate the development of genuinely complex software — not just websites and APIs, but the infrastructure that runs the internet.

The fact that one developer, working with AI assistance for a few weeks, could produce a Postgres-compatible database that passes 46,000+ regression tests and outperforms the original on multiple workloads would have sounded like science fiction in 2024. In 2026, it is simply the news of the day.

Whether pgrust reaches production readiness and widespread adoption remains to be seen. But the project has already demonstrated something important: the barrier to rewriting foundational software is collapsing. And when that barrier falls, everything is on the table — even Postgres itself.