pgrust: a Rust rewrite of Postgres that passes the regression suite and ships its own JIT

The problem pgrust attacks: Postgres outages, not Postgres syntax

pgrust is not trying to replace the SQL dialect. It is trying to replace the engine underneath it. The README frames the motivation around "the four horsemen behind thousands of Postgres outages," and two of the four named in the project's own writing are addressed directly by components pgrust adds: a query scheduler designed to keep any individual query from taking down the database, and a built-in OOM killer that gives the server control over what happens when memory runs low, instead of letting the OS OOM killer take out the whole process.

The intended audience is narrow. This is for engineers who already run Postgres, understand its operational failure modes, and want to see what the same system looks like when the executor, the concurrency model and the memory policy are redesigned in Rust. It is explicitly not for someone who needs production-ready Postgres today. The README's own answer to that case is one sentence: "If you need production ready Postgres today, use Postgres."

How pgrust is put together: a workspace of Postgres subsystems in Rust

The repository is a Cargo workspace, and the layout mirrors Postgres internals rather than hiding them. `crates/backend/replication/logical/worker`, `crates/backend/backup/basebackup`, `crates/backend/utils/adt/trigfuncs`, `crates/common/hashfn`: these are Postgres source directories translated into crate paths. That structure is the clearest evidence of the project's method. Each line is Rust, written to match the behavior of the C implementation, so the port is deliberately conservative at the boundary and inventive only in specific places.

The inventive places are listed in the README: a vectorized push-based, JIT compiled executor; a thread based concurrency model instead of Postgres's process-per-connection model; the query scheduler; and the OOM killer. The JIT is a copy-and-patch ARM64 compiler, described in the project's own post on JIT economics, and it only targets Graviton4. That is a hard architectural constraint, not a tuning knob: the README states pgrust will still work on other platforms but will not have similar performance.

Conformance is enforced against vendored upstream tests. The regression suite is PostgreSQL's own `src/test/regress`, vendored unmodified at `crates/postgres-18.6-reference/src/test/regress` and driven by upstream `pg_regress` against a pgrust server. The gate, per the README, is that every one of the 231 `parallel_schedule` files passes byte-for-byte against the vendor expected output.

Installing pgrust and running a first query

The README does not give a package-manager install line. The project points readers at https://pgrust.com to try it in a browser, and the repository carries a `rust-toolchain.toml`, a `Cargo.toml` workspace and a `scripts/pg-regress-fast.sh` driver, which is the path the project itself uses to build and exercise a server. A source build therefore starts from the toolchain file rather than from a release artifact.

git clone https://github.com/malisper/pgrust
cd pgrust
cargo build --release

The build resolves the workspace in `Cargo.toml`, which lists members such as `crates/backend/replication/logical/worker` and `crates/contrib/pgoutput`. Expect a long first compile; this is a database, not a library.

The project's own conformance driver is the most reliable first run, because it starts a pgrust server and pushes upstream test files through it. The README names it directly.

scripts/pg-regress-fast.sh

What you should see is the 231 `parallel_schedule` files passing byte-for-byte against the vendored expected output. If a schedule fails, you have learned something about your platform before you have loaded a single row of your own data.

For a real workload, the README is explicit about the posture: run pgrust in non-critical environments and keep Postgres as the source of truth for data you cannot afford to lose. That is also the framing of the v0.3 release, whose note reads "Try us on real world workloads in non-critical environments." Because pgrust is wire compatible, the practical first use is to point an existing client at it and replay read-only traffic, not to migrate writes.

The benchmark numbers, and the two caveats the README attaches to them

The performance claims are specific enough to check. On the ClickBench combined score, pgrust scored 18.5% faster than ClickHouse and hundreds of times faster than PostgreSQL, using pgrcolumnar, the builtin columnar layout. On sysbench-oltp, pgrust reached 30% higher throughput than Postgres 18.3 on read-only workloads at 300GB scale. Both were measured on `c8g.4xlarge` (AWS Graviton4) against PostgreSQL 18.3, with `fsync` on and durability settings unchanged from a default install. The harnesses live in `benchmarks/`.

The README volunteers two corrections that most project pages would leave out. First, the project had previously reported being over 50% faster than Postgres on OLTP; on Kubernetes the measured gap is 50-60% rather than 30%, and the authors say they have not isolated why the same binaries behave differently there than on bare EC2, so they quote the lower number. Second, the published binaries are generic for their architecture, while the benchmark numbers come from builds tuned for Graviton4 with `-Ctarget-cpu=neoverse-v2`. You will not reproduce them exactly from a download. Taken together, these mean the headline number is a ceiling for a specific machine and a specific build, and the project says so itself.

What pgrust cannot do: no extension ABI, no PL/Python, and a bug backlog

The limitations are stated plainly and they are severe for anyone with an existing deployment. Existing PostgreSQL extensions do not work. There is no stable extension ABI in pgrust yet. Some bundled contrib modules are ported, but PL/Python, PL/Perl and PL/Tcl are not. If your application depends on a procedural language or a third-party extension, pgrust is the wrong tool, and no amount of regression-suite compatibility changes that.

The second limitation is correctness confidence. The README's own framing is that the most common question is how anyone can trust pgrust, and that passing the test suite does not mean the code is correct. The project is running three programs against that gap: formal verification with Kani, covering 1000 of roughly 3000 user-facing Postgres functions, which found 12 divergences between pgrust and Postgres (four of them bugs in Postgres itself, per the README); simulation testing with Antithesis; and differential fuzz testing. Those are in progress, not finished. The README states the project is faster than Postgres and ClickHouse but "still has a lot of bugs," with testing and reliability as the number one priority.

There is also a hardware limitation that is easy to miss. The JIT compiler only targets Graviton4, and pgrust is specifically tuned for it. On other platforms it runs, but the performance case that justifies the switch does not carry over.

pgrust vs PostgreSQL, ClickHouse and Turso: different bets

The comparison the project invites is with PostgreSQL 18.3, because pgrust is wire and dialect compatible with it. The difference in approach is the executor and the process model. Postgres uses a process-per-connection model and a pull-based executor; pgrust uses threads and a vectorized push-based executor with JIT compilation, plus a scheduler and an OOM killer that change failure behavior under load. The trade is that you inherit Postgres's interface but not its decade of operational hardening, and you lose every extension that expects the C ABI.

Against ClickHouse, the difference is category. ClickHouse is an analytical database that was never trying to be a drop-in Postgres; pgrust uses pgrcolumnar, its builtin columnar layout, to compete on ClickBench while keeping the Postgres dialect. If your team already writes Postgres SQL and wants analytical speed without a second dialect, that is the bet pgrust makes. If you are happy maintaining a separate analytical store, ClickHouse is the more established answer and pgrust's 18.5% edge on one combined score is not a reason to move.

Turso appears in the same search space, but it is an embedded SQLite-compatible engine, not a Postgres-compatible server. Choosing between them is choosing between an embedded database and a server that speaks the Postgres wire protocol, and the two do not substitute for each other.

Licence and the cost of tracking a fast-moving engine

pgrust is AGPL-3.0, and the repository carries a separate `NOTICE` file alongside `LICENSE`. That is a stronger copyleft than PostgreSQL's permissive licence, and it matters if you plan to embed pgrust in a service or modify it. This is a description of the licence identifier, not legal advice; if your use involves distribution or a hosted offering, have counsel read the AGPL and the NOTICE before you build on it.

Upgrade cost is real. The last push was on 2026-09-18, and the release cadence is fast: v0.2 shipped on 2026-07-30 with the "faster than Postgres and Clickhouse" claim, and v0.3 followed on 2026-09-15. An engine at this stage changes behavior between releases by design, since the stated priority is testing and reliability rather than interface stability. There is no stable extension ABI to pin against, so the surface you would normally freeze for an upgrade does not exist yet. Budget for re-running your own workload on every release rather than assuming a smooth in-place upgrade.

Editorial conclusion

pgrust is worth adopting only for evaluation: a non-critical environment, a workload you can replay, and Postgres kept as the source of truth, which is exactly the posture the v0.3 release note describes. Do not adopt it if you depend on extensions (there is no stable extension ABI), if you need PL/Python, PL/Perl or PL/Tcl, or if your hardware is not Graviton4, where the README says performance will not be similar. Verify first that your schema and queries survive the regression-suite-compatible surface, then check `scripts/pg-regress-fast.sh` and the harnesses in `benchmarks/` to see what the project actually gates on before you trust a number.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. malisper/pgrust on GitHub
3. Project website
4. README
5. Releases