Imagine you decided to rebuild a classic car's engine, but instead of original parts you use parts 3D-printed from titanium. That's roughly what the pgrust project is doing. Developers took Postgres 18.3 and started methodically rewriting its internals in Rust.

It sounds like madness or a student experiment, but the numbers say otherwise. The project already passes more than 46,000 regression tests from the original Postgres. This isn't just a "database inspired by", but an attempt to create a binary-compatible replacement that understands the same data files and the same queries.

What is this project

pgrust is a complete overhaul of the PostgreSQL core. The main idea of its author, malisper, is that the original Postgres C code has become too complex over decades for radical changes. Implementing multi-threading or new storage mechanisms there is a task that would take years of discussions on mailing lists.

Rust here serves not just as a "safe language", but as a tool for rapid iteration. Developers use AI assistants to speed up porting, but they strictly control the results through Postgres's reference tests. If the original database throws an error on a malformed SQL query, pgrust must throw exactly the same error.

How pgrust differs from the original

The most interesting part lies in the plans and already implemented prototypes. The README mentions a new version that hasn't been released to the public yet, but the results are intriguing.

Instead of the classic "process per connection" model, which forces us to use pgbouncer or other proxies, pgrust is switching to threads. This immediately gives a huge boost on transactional workloads. According to the authors' measurements, this architecture runs 50% faster than the original.

For analytics, the numbers are even wilder: a 300x speedup is claimed. Developers are targeting Clickhouse-level performance while staying within the familiar Postgres interface.

Technical details and compatibility

The project maintains disk compatibility. You can take an existing data directory from Postgres 18.3 and "point" pgrust at it. It will pick up the files and start working.

To build from source, you'll need the standard set for working with Postgres: icu4c, openssl, and libpq. The process looks familiar to Rust developers:

PGRUST_PGSHAREDIR="$PWD/vendor/postgres-18.3/share" \
cargo build --release --locked --bin postgres

One interesting detail: when launching, you have to manually increase the stack limits (ulimit -s 65520), because some Postgres operations are very memory-hungry on the stack, and the Rust runtime behaves more modestly by default.

What's next on the roadmap

The project roadmap looks like every database administrator's wish list:

• Built-in connection pooling (goodbye, pgbouncer).
• Experiments with storage without Vacuum. If this can be implemented, pgrust will solve one of Postgres's most "painful" problems.
• Guardrails for bad queries. This is especially relevant now, when neural networks often generate SQL without much concern for indexes and execution plans.
• Fast data branching.

Is it worth trying

Right now, pgrust is not production-ready. The authors themselves admit this honestly. Extensions like PL/Python or PL/Tcl are not yet supported, and the performance in the public branch hasn't been fully optimized yet.

However, this is an ideal playground for experiments. If you've always wanted to dig into the guts of a DBMS but were scared off by the massive C codebase, pgrust is your chance. Rust code is an order of magnitude easier to read and modify.

You can try the project via Docker with a single command:

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

This will launch a container with pgrust and open the standard psql inside. For those who don't want to download anything, there's a demo on the official website running in WebAssembly, working right in the browser.

The project looks like one of the most ambitious open source challenges in recent times. Even if pgrust doesn't replace Postgres in the coming years, it will definitely become a testing ground for technologies that may later migrate to the main "elephant" branch.