// the find
malisper/pgrust
Postgres rewritten in Rust, now faster than Postgres and Clickhouse
A from-scratch Rust re-implementation of PostgreSQL 18 that aims to match it on the wire and in SQL behavior. It is worth reading for people interested in database internals or in a serious attempt to rebuild the executor, scheduler, and storage layers, but it is not a database to trust with data today.
- The compatibility claim is checkable. The regression suite is vendored unmodified under crates/postgres-18.6-reference and run by upstream pg_regress, and docs/conformance says exactly what the 46,066 figure counts (files, lines, or queries). That is more precise than most compatibility claims.
- Formal verification with Kani covers about 1,000 of roughly 3,000 user-facing functions, and the authors report 12 divergences from Postgres, four of which were bugs in Postgres itself. The proofs/ directory is where to check how far that coverage actually goes.
- The architecture changes are substantive design choices, not tuning: threads instead of processes, a priority-based query scheduler that demotes long-running queries, and pipelined fsync that releases locks before the fsync completes, with a written argument for why that is safe because the query is not acknowledged until the fsync finishes.
- The Docker image keeps the official postgres image's environment variables, init-script directory, and data volume layout, so it can replace the stock image in an existing compose file. The benchmarks/ harnesses are in the repo, so the performance claims can be rerun.
- The README says not to run it in production and that the top priority is still testing and reliability. Existing PostgreSQL extensions do not work and there is no extension ABI, which rules out a large share of real Postgres deployments. PL/Python, PL/Perl, and PL/Tcl are not ported.
- The headline numbers come from one vendor-run AWS Graviton4 instance type. The JIT only targets neoverse-v2, the published binaries are generic, and the authors say they cannot explain why the Kubernetes OLTP gap differs from bare EC2. The OLTP figure has already moved from over 50% to 30%, so treat the speedups as a direction rather than something to plan capacity around.
- Most x86 users will not get the advertised performance, since the JIT and the tuning are Graviton4-specific. The README is open about this, but it means the 'faster than ClickHouse' headline does not describe the experience on most hardware people will try it on.
- The project is not accepting pull requests right now, and the macOS binaries are not notarized. For a project whose stated priority is earning trust, closed contributions and unnotarized downloads leave outsiders with few ways to check the work beyond the test suite the authors wrote.