A successful build answers only the first question
pgrust gives database engineers a Rust reimplementation of PostgreSQL to investigate. Our recorded build succeeded, but our test command did not finish. That distinction matters when deciding whether to explore its architecture or trust it with data.
The current repository README describes v0.4-beta as PostgreSQL 18.6 compatible. It also says the software still has many bugs and recommends PostgreSQL for production use. Wire and SQL dialect compatibility are project claims, not a guarantee that every client, extension or workload will behave identically.
What our October 4 run establishes
Our stored run began at 2026-10-04T03:40:08.815Z and checked commit 79ad992ede22bcf6ae0c4fdead6fb01eeac5a990, dated September 15, 2026. The sandbox configuration recorded 3 CPUs, 12 GB of memory and image label lab-rust:1. That label does not establish the actual Rust compiler version.
The dependency step completed in 30 seconds. Its parser recorded 1,796 packages, while its tail shows dependency downloads. This does not prove that pgrust was installed as a usable server. The build step completed successfully in 377 seconds; its tail reports an unoptimized dev profile with debug information. The recorded step duration and Cargo's own compilation duration cover different scopes.
The cargo test step reached the 900-second limit and exited with code 124. The parser summary recorded 619 passed, zero failed and 43 suites. These are partial recorded counts: exhaustive unique coverage has not been verified, and the command did not complete. The final tail shows the range stack-guard test range_deep_nesting_raises_54001_and_does_not_abort running for over 60 seconds. It provides no final outcome or established cause for that delay.
This record supports a successful build and an incomplete test run. It does not establish a successful server startup, installed-binary verification, crash recovery, performance or production readiness. No new execution was performed for this review.
The collector also recorded 403,712 files, 4,765,324 lines and 513.5 MB. Their source-only scope is not established, so they should not be read as a clean source-code inventory. Its detection flags found zero CI workflows and no Dockerfile, Compose file or top-level tests directory. Those flags do not establish an absence of tests or Docker support: the test tail contains tests, and the README documents a published Docker image.
Keep the measured checkout separate from current setup
The README pinned to our measured commit describes v0.3, PostgreSQL 18.6 compatibility and native binaries that borrow PostgreSQL 18's initdb, psql and share files. Its JIT targets Graviton4. Those are historical setup constraints for that snapshot.
The current v0.4-beta README describes self-contained release tarballs containing bin/postgres, bin/initdb, bin/psql and their share files. It specifies glibc 2.34 or newer for Linux binaries and macOS 11 or newer for macOS binaries. The macOS binaries are signed ad hoc but are not notarized. Current source instructions pin Rust 1.96.0 and require RE2 for release builds.
The current Docker instructions use the explicit v0.4-beta tag for amd64 or arm64. The README says latest still points to v0.3. It also says v0.3 columnar tables require dump and restore before use with v0.4-beta. These are documented instructions and constraints; our run did not validate either distribution path.
The architecture has changed beyond the original review
The current README calls the query engine Gravity. It describes a vectorized, push-based executor whose JIT emits AArch64 and x86-64 machine code, with WebAssembly support in the browser build. The old statement that the current JIT only targets Graviton4 is therefore outdated.
Connections and parallel workers still use threads. The README describes query scheduling and work stealing, plus an automatic memory manager covering the buffer pool, columnar caches and running queries. Near the memory limit, it says pgrust cancels the statement holding the most memory. These are implementation descriptions, not behavior we exercised in the sandbox.
The current extension position also needs precision. Arbitrary PostgreSQL extensions do not work out of the box because pgrust has no stable extension ABI, but the project lists bundled ports including pgvector, pg_cron, pg_stat_statements and postgres_fdw. PL/Python, PL/Perl and PL/Tcl remain unsupported. Columnar tables currently lack ON CONFLICT and MERGE support, and UTF8 is the only server encoding listed.
Closed reports still explain useful limits
Issue 76 originally reported that file_fdw accepted a program option and then panicked during SELECT. On September 10, 2026, the maintainer reported that the path had been implemented with its privilege check and a regression fixture, and closed the issue. It should not be presented as an outstanding defect. We did not rerun the reproducer.
Issue 67 raised a crash-isolation concern through static review, without demonstrating corruption. On September 10, the maintainer reported a merged fix releasing held LWLocks on crash-class exits, with a unit test, and closed the issue. The same update retained the architectural contract for hard signals: the whole process dies, with an external supervisor and WAL recovery responsible for restart. Closure addresses the reported lock-handling work; it does not turn threads into separate fault-isolated processes.
Compatibility claims and benchmarks need their own evidence
The pinned v0.3 README claimed 46,066 PostgreSQL regression tests passed, while also directing readers to conformance documentation about what that figure counts. That is an upstream claim, separate from our partial cargo test summary. Neither figure proves general correctness.
Likewise, the v0.2 release compared tuned Graviton4 builds against PostgreSQL 18.3. It is historical benchmark evidence, not the current compatibility version or a result from our sandbox. Current README performance claims concern different software and stated workloads. We measured no database workload and cannot select a performance winner from this run.
For production-ready PostgreSQL, the project's own recommendation is PostgreSQL. For a column-oriented analytical database, ClickHouse is a relevant separate evaluation. Those choices answer different requirements; neither is ranked by our build timing.
How to use this review
The scores use a five-point editorial rubric: 1 means substantial barriers or insufficient evidence for the intended use; 2 means significant limits; 3 means a usable evaluation path with unresolved questions; 4 means clear supporting documentation with bounded gaps; 5 requires broad corroboration in that category. These are judgments about the supplied evidence, not benchmark results. Community scoring concerns the documented participation path, not adoption, and maturity concerns production suitability.
For a disposable trial, follow the current README, select an explicit release and check the server's reported version after connecting. Test the particular SQL behavior and extensions you need. Keep important data in PostgreSQL while evaluating pgrust; our build result and incomplete test run do not justify moving that boundary.