PGRust: A Rust Rewrite of PostgreSQL That Passes All Regression Tests

PostgreSQL has been one of the most successful open-source projects ever shipped. It's also built on roughly a million lines of C code and an architectural model designed in a different era of computing. PGRust is an attempt to change both of those things at once: a complete, from-scratch rewrite of PostgreSQL in Rust, built by former Heap CEO Malcolm Matis using eight parallel AI coding agents.

The current v0.1 release passes all 46,066 queries in the PostgreSQL 18.3 regression suite, speaks the native wire protocol, and can boot from an existing Postgres 18.3 data directory. An unreleased version in development claims a thread-per-connection model, 50% faster transactional performance, and roughly 300x faster analytical performance. This article covers what PGRust is, why it was built, how to run it, and what to make of its claims.

Why rewrite PostgreSQL

The C codebase

PostgreSQL is approximately a million lines of C. The language is not memory-safe, which means developers must manage memory manually. The Postgres community has done an impressive job with this over decades, but the underlying risk remains. The codebase's size and age also raise the barrier to entry for fundamental architectural changes.

The process-per-connection model

The more significant architectural issue is how PostgreSQL handles connections. When a client connects, the main server process forks itself, creating a new operating system process for that single connection. This provides strong isolation: a crash in one connection's process can't bring down others. But it comes with real costs.

Each process consumes significant memory. For applications with thousands of concurrent connections, that adds up fast. Creating and tearing down OS processes is also relatively slow, which is why most production Postgres deployments add an external connection pooler like PgBouncer in front of the database. The pooler maintains a smaller set of persistent connections and assigns them to incoming clients. It works, but it's an extra layer of infrastructure that exists purely to compensate for an architectural choice made when most servers had a fraction of today's cores.

Because each connection runs in its own process with isolated memory, sharing state across connections is also difficult. Caches and other computed data can't be easily shared, so each process often ends up doing redundant work.

What PGRust is

PGRust is a clean-slate rewrite of PostgreSQL in Rust, targeting drop-in compatibility with the C version. Same query results, same wire protocol, same disk format.

The choice to start from scratch rather than fork the existing codebase was deliberate. An extension can't change fundamental architecture. A fork inherits the memory-safety risks of C and creates an ongoing maintenance burden of staying in sync with upstream. A clean rewrite in Rust allows architectural experimentation that simply isn't practical otherwise.

The project is available on GitHub under the malisper account.

Running PGRust with Docker

The easiest way to try PGRust is via the official Docker image. Pull v0.1:

docker pull malisper/pgrust:v0.1

Start the container with a password and a name:

docker run -d --name pgrust-demo -e POSTGRES_PASSWORD=secret malisper/pgrust:v0.1

Connect using a standard psql client:

docker exec -it pgrust-demo psql -U postgres -h 127.0.0.1

You'll see the standard postgres=# prompt. From a client's perspective, this is indistinguishable from connecting to a normal Postgres server.

Basic interaction

Check the version to confirm what you're connected to:

SELECT version();

pgrust 18.3 on aarch64-linux-gnu, compiled by clang-21.0.0, 64-bit

Create a table, insert data, and query it:

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    name TEXT,
    created_at TIMESTAMP DEFAULT now()
);

INSERT INTO users (name) VALUES ('Subscribe'), ('Better Stack');
SELECT * FROM users;

Both execute correctly and return results identical to what standard PostgreSQL would produce.

Query planning

PGRust has a fully functional query planner. The EXPLAIN ANALYZE command works as expected:

EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM users WHERE id = 1;

PGRust correctly selects an index scan on the primary key. Insert 100,000 rows and query on an unindexed column:

INSERT INTO users (name)
SELECT 'User ' || generate_series FROM generate_series(1, 100000);

EXPLAIN (ANALYZE, BUFFERS) SELECT COUNT(*) FROM users WHERE name LIKE 'User 5%';

The planner switches to a sequential scan, the correct choice when no suitable index exists. PGRust's query planner makes the same decisions as standard PostgreSQL.

The unreleased version: thread-per-connection

The v0.1 release demonstrates compatibility. The architectural work is in an unreleased version that hasn't been made public yet. The key change is replacing the process-per-connection model with a thread-per-connection model.

In a thread-per-connection model, the database runs as a single process. Each connection gets a thread within that process rather than a new OS process. Threads are far lighter than processes and share the same memory space, which means:

• Connection overhead drops significantly
• Caches and computed state can be shared across connections without inter-process communication
• The need for an external connection pooler is greatly reduced

The performance claims for this unreleased version are 50% faster on transactional workloads and approximately 300x faster on analytical workloads compared to standard PostgreSQL.

These numbers are currently unverified and come from an unreleased codebase. They should be treated as directional claims, not established benchmarks.

AI-assisted development

PGRust is also an experiment in what AI can do at scale. The project was built by a very small team, with eight parallel AI coding agents handling a large portion of the translation work from C to Rust. The developers guided, corrected, and structured the output rather than writing every line manually.

The result is over 450,000 lines of Rust that covers all major PostgreSQL subsystems. A rewrite of this scope would traditionally require a large team and many years. PGRust makes a case that AI-assisted development can change that math significantly.

Community reaction

The reception has been a mix of genuine excitement and reasonable skepticism.

The case for optimism: passing the full PostgreSQL regression suite is a serious technical achievement. It demonstrates a depth of compatibility that goes well beyond surface-level parsing. The project's approach of using the real Postgres test suite as the oracle is methodologically sound.

The case for skepticism: regression tests cover expected behavior under normal conditions. The decades of hardening that make PostgreSQL reliable come from years of production exposure to edge cases, crash recovery scenarios, replication failures, and obscure query patterns that no test suite fully captures. AI-generated code also raises legitimate questions about long-term maintainability.

Both positions are reasonable. PGRust is a proof-of-concept with genuine technical credibility, not a production database.

Where things stand

The developers are clear that PGRust is not production-ready. The current release is a compatibility demonstration. Major features, particularly around the extension ecosystem, are still incomplete.

The roadmap includes multithreaded internals, built-in connection pooling, adaptive query planning, improved JSON workload support, fast forking and branching, and storage experiments that could eliminate the need for VACUUM. No production release date has been given.

For developers interested in databases, Rust, query execution engines, or AI-assisted development at scale, PGRust is worth exploring. The GitHub repository is public, the Docker image runs in minutes, and the source code is readable. The project also has a browser demo that runs PGRust compiled to WebAssembly, no Docker required.

Got an article suggestion? Let us know

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.