Can Rust Replace PostgreSQL? pgrust Passes All Official Tests

pgrust overview

pgrust is an independent Rust implementation of PostgreSQL that passes all 46,066 official PostgreSQL regression queries. It implements the PostgreSQL wire protocol, supports the standard psql client, real SQL statements, query planning, and a storage engine, and can start from an existing PostgreSQL 18.3 data directory. The project is explicitly marked as not production‑ready.

Why reconsider PostgreSQL’s architecture

PostgreSQL’s traditional per‑client‑process model creates a separate operating‑system process for each connection. This design yields strong isolation but also incurs per‑connection process and memory overhead, forces the use of external connection pools for high concurrency, makes sharing internal state between components difficult, and raises the cost of low‑latency coordination among internal modules.

What pgrust implements

pgrust is a standalone PostgreSQL implementation that aims to preserve PostgreSQL’s on‑disk format, client experience, and observable behavior while rewriting the core engine in Rust. The current release targets PostgreSQL 18.3 compatibility and includes:

Support for PostgreSQL’s wire protocol.

Compatibility with the standard psql client.

Full support for regular SQL operations and the query planner.

Passes PostgreSQL’s official regression and isolation test suites.

Ability to launch from an existing PostgreSQL 18.3 data directory.

Practical usage example

Using the official Docker image, a user can connect with psql, view version information, create tables, insert data, and run EXPLAIN to see execution plans. After inserting 100,000 rows, the client experience remains indistinguishable from a regular PostgreSQL instance.

Why not an extension or a fork

Extensions

Extensions add functions, types, or indexes but run on top of PostgreSQL’s original core, so they cannot replace the per‑connection process model or internal execution mechanisms.

Forks

Forking the codebase allows core changes but inherits the entire legacy architecture and requires continuous synchronization with upstream releases, turning each PostgreSQL version into a maintenance burden. Projects such as CockroachDB and Yugabyte follow a different path as independent distributed databases and do not aim for full PostgreSQL compatibility.

pgrust occupies a niche as an independent implementation that strives to be a drop‑in replacement for PostgreSQL behavior.

Architectural experiment: thread‑per‑connection

An unpublished development version proposes replacing the process‑per‑connection model with a thread‑per‑connection model. Potential benefits listed are:

Reduced resource overhead per connection.

Less reliance on external connection pools.

Easier sharing of internal state between components.

Space for built‑in connection pooling and future storage experiments.

Improved performance for certain transactional and analytical workloads.

Trade‑offs

Process isolation provides a strong safety boundary: a fault in one process is contained. Threads share the same process address space, so a buggy extension or memory error could affect the entire server, removing mature safety guards. The core question is how to balance performance, shared capability, fault isolation, and ecosystem compatibility.

AI programming agents as a catalyst

The rewrite was driven by Michael Malis and Jason Seebol, who used AI programming agents extensively. The public release retains PostgreSQL’s original structure to prioritize compatibility verification; more aggressive architectural changes reside in the unpublished version. This raises the broader question of whether AI‑driven cost reductions enable developers to revisit the architecture of long‑standing infrastructure more frequently.

Performance claims (unpublished)

The thread‑per‑connection version claims roughly a 50% improvement for transactional workloads and up to 300× for analytical workloads. These numbers are not publicly verifiable, and the implementation details remain hidden.

What passing 46,066 tests really means

Passing all official regression queries demonstrates alignment with many known PostgreSQL behaviors, SQL semantics, edge cases, and historical compatibility requirements. However, regression tests cannot replace years of production experience. Missing validation areas include long‑running stability, crash recovery, replication, failover, extreme concurrency, obscure edge cases, and third‑party extension compatibility.

Tests ≠ production trust

A project can pass every known test yet still fail in unforeseen scenarios. Generating hundreds of thousands of lines of code is one challenge; ensuring those lines survive years of production pressure is another.

Ecosystem compatibility gap

PostgreSQL’s strength also lies in its rich ecosystem of extensions, client libraries, operational tools, migration workflows, and accumulated expertise. pgrust’s current limitation is incomplete extension compatibility, meaning many production‑level plugins and tools may not work seamlessly.

Production readiness assessment

The project states it is not ready for production: performance optimizations are unfinished, and ecosystem compatibility is still under construction. Nevertheless, the codebase is valuable for developers interested in:

PostgreSQL and database kernel development.

Rust‑based query execution and storage engines.

Database compatibility testing.

Client driver and wire‑protocol implementation.

AI‑assisted software rewriting and infrastructure engineering.

Developers can run the Docker image, connect with client libraries, execute typical SQL workflows, and inspect the source code. Repository: https://github.com/malisper/pgrust (demo site: pgrust.com).

Open questions

Two ongoing questions merit attention: whether the thread‑per‑connection model can deliver real benefits without sacrificing reliability, and whether AI programming agents will make large‑scale infrastructure rewrites a routine experiment rather than a rare, high‑risk gamble.