A rewrite with a much harder target than SQL syntax
pgrust is not a PostgreSQL-inspired database with a familiar query language. It aims to reproduce PostgreSQL 18.3 behavior closely enough that existing clients can use its wire protocol and SQL dialect, while the server itself is Rust. That means copying thousands of functions, catalog behaviors, error cases, transaction rules, and storage assumptions before the new architecture earns practical value.
The project is refreshingly blunt about its status: it is not production-ready, it has bugs, and users should not store important data in it. That warning is more important than every performance number on the page. Version 0.2 is a research release for testing ideas and compatibility, not a safer PostgreSQL delivered by a memory-safe language. The code still uses unsafe where PostgreSQL's untyped datum representation and binary layouts demand it.
The architecture is genuinely interesting
The rewrite creates room to challenge old process and execution designs. pgrust uses threads for connections and parallel work, then adds a scheduler that reduces the priority of long-running queries so one expensive job is less able to monopolize the server. Work stealing can assign idle threads to queries already in progress. A built-in memory monitor chooses a worker to terminate near the limit instead of waiting for the operating system to kill the whole database.
The analytical path is more radical. A vectorized, push-based executor operates on batches, supports operator fusion, and includes a JIT that emits machine code directly. The pgrcolumnar layout adds dictionary encoding and other compression techniques. A cache-aware hash table serves aggregations. Pipelined fsync releases locks before the write finishes but delays acknowledgment and visibility until durability completes. These are coherent database-engine ideas, not a surface-level language port.
They are also incomplete and platform-specific. The JIT currently targets the Neoverse V2 cores in AWS Graviton4. Other platforms can run the server, but the README says they will not see similar performance. Planner support for JSON, an undo-log design, instant forking, autoscaling, and an embedded edition remain roadmap items.
Compatibility testing is stronger than the headline suggests
The project says it passes all 46,066 checks in PostgreSQL's regression suite. That is a meaningful milestone because the suite compares large amounts of visible SQL behavior. The maintainers correctly say passing it does not prove correctness. Recent open reports make the boundary concrete: source reviewers found unported logical-replication cases that panic, missing bootstrap rows that appear to break cross-encoding conversion, and a path that may reveal superuser-only configuration values to ordinary users. Some reports are based on static code inspection rather than live reproduction, but they identify specific reachable code and deserve investigation.
The formal work is even more notable. The proof ledger lists 3,189 SQL-callable internal functions, with 1,086 proved equivalent to vendored PostgreSQL C within recorded bounds and another 26 covered by weaker differential testing. The campaign reports finding eight pgrust bugs and four upstream PostgreSQL bugs. Each harness depends on shipped Rust code and records its limits, while negative controls are expected to fail so a broken proof rig cannot pass quietly. That methodology makes the evidence inspectable, but roughly two-thirds of the listed functions are not in the proved group.
Read the benchmark fine print twice
The release reports a ClickBench combined score 18.5 percent faster than ClickHouse, hundreds-fold gains over PostgreSQL on that analytical workload, and 30 percent higher read-only sysbench throughput than PostgreSQL 18.3 at 300 GB. The project says an outside reviewer controlled the machines and reproduced release-candidate runs. It publishes scripts, common configurations, baseline provenance, PGO procedures, durability settings, and raw-run output structure. fsync, synchronous commit, and full-page writes remain at PostgreSQL defaults. This is far better disclosure than a chart without a harness.
These numbers are not a universal ranking. The benchmark kit uses AWS Graviton4, specific gp2 and local NVMe storage, separate load generation, multi-hour runs, and a PGO binary tuned for Neoverse V2. Its current “what to expect” section describes a ClickBench combined score around 7 percent ahead of the pinned ClickHouse row and read-only gains in a 1.25 to 1.40 range, while read-write performance is near parity. That guidance is more conservative than the release headline. Use the scripts to evaluate a relevant workload instead of carrying one percentage into purchasing decisions.
Trying it is easy only through Docker
The Docker image is the sensible evaluation path. It accepts familiar PostgreSQL image variables, initializes the standard data volume, supports amd64 and arm64, and listens for normal psql clients. The WebAssembly demo is even quicker for testing queries without installation.
Native setup exposes how much PostgreSQL infrastructure the rewrite still borrows. pgrust has no initdb or psql, and it reads timezone and other shared files from a PostgreSQL 18 installation. The quick start requires environment variables for those paths, unusually high stack settings, and flags for the current I/O implementation. macOS downloads are not notarized. A source build pins Rust 1.96 and intentionally requires RE2 for release performance. None of that is disqualifying for researchers, but it is far from a drop-in server binary.
The ecosystem gap decides the verdict
Existing PostgreSQL extensions do not work because there is no stable extension ABI. Only some bundled contrib modules have been ported, and PL/Python, PL/Perl, and PL/Tcl are absent. This alone excludes many real deployments, even before reliability and security concerns. The project also is not actively accepting pull requests, directing potential contributors to Discord while welcoming bug reports.
Development is active: the repository was pushed days before this review, v0.2 shipped recently, and detailed reports and reliability fixes continue. The 24 open items include a pull request, so that number is not a pure bug count. Health, however, is not maturity.
pgrust is worth watching because it tests whether PostgreSQL compatibility can coexist with a new executor and concurrency model. Its team publishes unusually strong evidence and unusually clear warnings. Respect both: experiment freely, reproduce claims, and keep valuable data on PostgreSQL.