PostgreSQL compatibility is a larger target than its SQL grammar
pgrust is not a new database with PostgreSQL-flavored syntax. It aims to match PostgreSQL 18.3 behavior closely enough that existing clients can use the same wire protocol and SQL dialect. That target includes catalog details, errors, transactions, built-in functions, storage behavior, and edge cases accumulated over decades. Rewriting the server in Rust does not make those semantics appear automatically.
The README gives the correct warning in plain language: pgrust is not production ready and users should not store important data in it. Version 0.2 is a research server with known bugs. It also contains unsafe code where internal values and memory layouts must match PostgreSQL. Treating the language choice as a blanket safety guarantee would ignore both the project's status and its own explanation.
Threads and a new executor create the interesting experiments
Connections and parallel workers run as threads rather than PostgreSQL's separate backend processes. A query scheduler can lower a long-running query's priority, and work stealing assigns idle threads to work already in progress. A built-in out-of-memory mechanism chooses a worker to kill as memory runs low, seeking a more controlled outcome than an operating-system OOM kill.
The analytical path uses a vectorized, push-based executor, operator fusion, and a JIT that emits machine code directly. pgrcolumnar supplies a column-oriented layout with compression, and aggregation uses a cache-aware hash table. Pipelined fsync releases locks before the write completes but withholds acknowledgement and visibility until durability finishes. These changes make pgrust an architectural experiment rather than a line-for-line language port.
Hardware limits matter. The JIT currently targets Neoverse V2 on AWS Graviton4. The README says the server works on other platforms without similar performance, and the published benchmark binaries differ from generic downloads because the measured builds were tuned for Graviton4. The repository includes benchmark harnesses, but readers should reproduce a relevant workload rather than treating the project's headline as a universal database ranking.
What happened when we ran it
Our sandbox installed 1,743 Rust packages in 35 seconds and built the project in 443 seconds. commit 438c8c4 contained 4,806 files, about 1,736,820 lines of source, and 109.3 MB before dependencies. It had a Dockerfile, no tests directory, and 0 CI workflow files. The run used an unprivileged rust:1-bookworm container with 3 CPUs and 12 GB of RAM.
Tests ran for 563 seconds and reported 152 passed with 1 failed out of 153. The failing case, init_database_collation_libc_noncc_builds_collator, called Result::unwrap() on a PostgreSQL error saying it could not create locale en_US.UTF-8 because the locale did not exist. Cargo exited with code 101 and identified the pg_locale library target for rerunning.
The log supports a narrow conclusion: our fresh Debian image lacked a locale expected by that test. It does not show a collation algorithm mismatch or database crash. A source contributor can make the environment requirement explicit and repeat the test after provisioning the locale. The lack of a GitHub Actions workflow in the checkout also means a reviewer cannot infer repository-hosted CI behavior from workflow files.
Compatibility evidence is strong, while production evidence is not
The project says it passes PostgreSQL's 46,066-case regression suite and discusses differential fuzzing, simulation testing, and Kani proofs for SQL-facing functions. The maintainers also say the regression suite does not establish correctness. That is the right framing for a database, where recovery, concurrency, long-running state, upgrades, and unusual inputs can fail outside a query compatibility suite.
Open reports show the distance. Issue 76 identifies a file_fdw path where a foreign table accepts a program option, then a SELECT reaches an explicit panic because that execution lane is unported. The reporter also checked a beta branch and found the same branch. A database server should reject an unsupported option as a controlled SQL error rather than accept it and panic later.
Issue 67 raises a design concern rather than claiming a reproduced corruption. PostgreSQL isolates backends in processes; pgrust shares one process across backend threads. The report explains that a Rust panic can enter a recovery path, while a memory-safety signal kills the whole server and depends on an external supervisor for restart. Its author explicitly says they did not demonstrate corruption. That distinction makes the issue useful without overstating it.
Docker is the shortest path because native use borrows PostgreSQL tools
The Docker image mirrors the official PostgreSQL image's environment variables, initialization scripts, and data-volume path. It supports amd64 and arm64 and is the sensible route for a disposable trial. A browser build offers an even quicker way to exercise SQL without preserving data. Neither path changes the production warning.
Native setup still installs PostgreSQL 18 because pgrust does not ship its own initdb or psql. The server needs PostgreSQL share and timezone directories, raised stack limits, and current I/O settings from the quick start. A source release build requires RE2 on purpose; the fallback regex engine is considered too slow. macOS downloads are not notarized, which adds a Gatekeeper step for browser downloads.
Existing PostgreSQL extensions cannot load because pgrust lacks a stable extension ABI. Some bundled contrib modules are ported, while PL/Python, PL/Perl, and PL/Tcl are not. The roadmap mentions more planner and storage work, but those are future desires, not delivered compatibility. GitHub showed 4,714 stars, 13 combined open issues and pull requests, a last push on August 13, 2026, and a v0.2 release on July 30.
pgrust is worth reading and testing because it asks serious questions about PostgreSQL's executor and process model. The successful 443-second build and nearly clean suite support that use. The project's own status, missing extension ecosystem, platform-specific JIT, and open panic path rule out production. Respecting that line is part of taking the work seriously.