Postgres in Rust Passes the Ultimate Compatibility Test

Rewriting a massive, decades-old C codebase in Rust is a well-worn industry trope, often dismissed as an academic exercise. But when the target is PostgreSQL, the world's most trusted relational database, the stakes are different. The database is famous for its rock-solid reliability, a reputation earned through decades of edge-case handling and rigorous testing.

That is why the latest milestone from pgrust is a genuine turning point. Developed by Michael Malis and Jason Seibel, this experimental rewrite of Postgres in Rust now passes 100 percent of the upstream Postgres regression and isolation tests. It successfully matches expected output across 46,066 queries. It is not just a toy clone. It is disk-compatible with Postgres 18.3, meaning it can boot directly from an existing Postgres data directory.

The Oracle of 46,066 Queries

To appreciate this achievement, you have to understand how Postgres maintains its stability. The upstream project relies on an exhaustive suite of regression tests that cover everything from complex SQL parsing to transaction isolation levels.

The creators of pgrust did not try to write a new database from scratch and hope for the best. Instead, they treated the official Postgres 18.3 codebase as an oracle. By targeting exact compatibility with the expected outputs of the official test suite, they forced the Rust implementation to respect the precise, sometimes quirky, behaviors of the original C engine.

The fact that pgrust also passes the isolation tests is particularly telling. Isolation tests verify that the database handles concurrent transactions correctly under various isolation levels, preventing race conditions, dirty reads, and serialization anomalies. Achieving 100 percent compatibility here means the core transaction engine and concurrency controls in pgrust are behaving exactly like the C original.

The Architectural Pivot: Why Rust Matters

If Postgres is already excellent, why go through the pain of a Rust rewrite? The answer lies in the limitations of Postgres's aging architecture.

Postgres was designed in an era of single-core machines. To handle concurrency, it uses a process-per-connection model. Every time a client connects, Postgres forks a new backend process. While this isolation prevents a crash in one connection from taking down the entire database, it introduces massive overhead. It is the reason why developers must use external connection poolers like PgBouncer in production.

By moving to Rust, pgrust opens the door to a multithreaded architecture. The project's roadmap explicitly targets multithreaded internals and built-in connection pooling. This could drastically reduce memory usage and connection overhead, allowing a single server to handle tens of thousands of concurrent connections without sweating.

Furthermore, the rewrite makes it easier to experiment with storage engines. One of the most painful aspects of running Postgres at scale is table bloat and the vacuuming process. The pgrust roadmap includes plans for "no-vacuum" storage designs, a change that would be incredibly risky and difficult to implement in the legacy C codebase but becomes feasible in a modern, memory-safe language.

The Developer Reality Check

Before you plan a migration, let's look at the practical trade-offs. The project is licensed under AGPL-3.0, and the maintainers are clear: pgrust is not production-ready yet.

First, it is not performance-optimized. While it passes the correctness tests, it will not match the throughput or latency of a highly tuned C-based Postgres instance today. The current focus is on stability and bug-bashing rather than speed.

Second, the extension ecosystem is a major hurdle. Standard procedural language extensions like PL/Python, PL/Perl, and PL/Tcl are not compatible. While some bundled contrib modules have been ported, any production deployment relying on third-party C extensions will find pgrust a non-starter for now.

However, if you want to experiment, getting started is straightforward. You can run a pinned launch image using Docker:

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

To verify it is running, connect using the standard psql client:

docker exec -it -e PGPASSWORD=secret pgrust psql -h 127.0.0.1 -U postgres

If you want to build it from source to hack on the internals, you will need dependencies like icu4c, openssl@3, and libpq. On macOS, you can set up your environment and build the binary with Cargo:

export LIBRARY_PATH="$(brew --prefix openssl@3)/lib:${LIBRARY_PATH:-}"
export PKG_CONFIG_PATH="$(brew --prefix openssl@3)/lib/pkgconfig:$(brew --prefix icu4c)/lib/pkgconfig:${PKG_CONFIG_PATH:-}"
export PATH="$(brew --prefix libpq)/bin:$PATH"

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

You can then initialize a data directory and run the server:

target/release/postgres --initdb \
  -D /tmp/pgrust-data \
  -L "$PWD/vendor/postgres-18.3/share" \
  --no-locale \
  --encoding UTF8 \
  -U postgres

ulimit -s 65520
RUST_MIN_STACK=33554432 target/release/postgres \
  -D /tmp/pgrust-data \
  -F \
  -c listen_addresses= \
  -k /tmp \
  -p 5432 \
  -c io_method=sync \
  -c max_stack_depth=60000

The Long Game

The real value of pgrust is not as a drop-in replacement today, but as a catalyst for database innovation.

By proving that a Rust rewrite can achieve 100 percent compatibility with the Postgres test suite, the creators have lowered the barrier to entry for deep database experimentation. Features that have been stalled in the upstream Postgres mailing lists for years, like native multithreading or alternative storage engines, can now be prototyped rapidly in Rust.

Whether pgrust eventually becomes a production-grade database or remains a highly successful research vehicle, it has already changed the conversation. It proves that even the most complex, battle-tested C systems can be successfully rebuilt in a modern language without sacrificing correctness.