[opensourcedex]

pgrust is a free, open source databases project written in Rust and released under AGPL-3.0. It has 5,072 GitHub stars, 191 forks and 6 open issues, and was last pushed 10 hours ago. On this registry it ranks #144 of 203 tracked projects in Databases, with 5 head-to-head comparisons available.

What is pgrust?

pgrust is an AGPL-3.0 Rust re-implementation of PostgreSQL that is wire compatible and SQL dialect compatible with Postgres, aimed at engineers who want to see what Postgres would look like if it were built in 2026.

What it is

pgrust lives in the PostgreSQL ecosystem as a ground-up rewrite of the Postgres server in Rust, with every line written to match the behavior of the C implementation. It speaks the Postgres wire protocol and the Postgres SQL dialect, and it passes all 46,066 tests in Postgres' regression suite. Rather than patching the existing C codebase, the project re-architects core pieces of the engine in Rust, including a vectorized push-based JIT compiled executor, a thread-based concurrency model, a query scheduler, and a built-in OOM killer.

The concrete problem it goes after is database outage behavior. The scheduler is designed to keep any individual query from taking down the whole database, and the built-in OOM killer gives pgrust control over what happens when memory runs low, reducing the chance that the operating system OOM killer takes down the entire database. In effect it replaces the Postgres C server process with a Rust server that targets two of the four horsemen behind thousands of Postgres outages. The tradeoff is that existing PostgreSQL extensions do not work, because there is no stable extension ABI in pgrust yet.

Key capabilities

  • Wire compatible and SQL dialect compatible with Postgres, passing all 46,066 tests in Postgres' regression suite.
  • A vectorized push-based, JIT compiled executor; the JIT compiler targets Graviton4 only.
  • A thread-based concurrency model replacing the process-per-connection approach of the C server.
  • A query scheduler designed to keep any individual query from taking down the database.
  • A built-in OOM killer that reduces the chance of the whole database being killed by the OS OOM killer.
  • pgrcolumnar, the project's builtin columnar layout, used for its ClickBench results.
  • Measured on c8g.4xlarge against PostgreSQL 18.3: 18.5% faster than ClickHouse on the ClickBench combined score, and 30% higher throughput than Postgres 18.3 on read-only sysbench-oltp at 300GB scale, with fsync on and harnesses in the benchmarks/ directory.

Who uses it and how

  • Analytics-focused teams evaluating columnar engines, using pgrcolumnar on ClickBench-style workloads where the combined score lands ahead of ClickHouse.
  • Operators who have been burned by Postgres outages, using the query scheduler and built-in OOM killer as the mitigation path.
  • The project's own developers, who run pgrust internally while keeping Postgres as the source of truth for data they cannot afford to lose.
  • Teams on AWS Graviton4 hardware, since the engine is tuned for Graviton4 and the JIT compiler targets that CPU.
  • Not extension-dependent teams, since existing PostgreSQL extensions do not work and PL/Python, PL/Perl, and PL/Tcl are not ported, though some bundled contrib modules are.

Getting started

The README points to a browser trial at pgrust.com, and the project publishes binaries that are generic for their architecture rather than tuned builds. The benchmark harnesses live in the benchmarks/ directory so the released numbers can be rerun.

How it compares

Among the tools named in the facts, Postgres and ClickHouse, pgrust sits between the two: it reports 18.5% faster than ClickHouse on the ClickBench combined score and hundreds of times faster than PostgreSQL on the same run, while PostgreSQL 18.3 is the reference point for the sysbench-oltp comparison. The project still tells anyone who needs production-ready Postgres today to use Postgres, and it recommends keeping Postgres as the source of truth for data you cannot afford to lose.

When to use it — and when not to

Use it for evaluation, internal testing, and analytics experiments on Graviton4, where the columnar layout and JIT executor are strongest. Do not put production data you cannot lose behind it: there is no stable extension ABI, existing extensions fail, and the project itself says it still has a lot of bugs and that testing and reliability are the current priority. Two further caveats matter for anyone reproducing results: published binaries are generic for their architecture while the benchmarks come from builds tuned with -Ctarget-cpu=neoverse-v2, and the larger 50-60% OLTP gap seen on Kubernetes has not been isolated.

project readme (upstream, from github) — read inline

pgrust

A Rust rewrite of Postgres that's faster than Postgres and ClickHouse.

Postgres 18.6 Regression suite: 100% Version: v0.3 License: AGPL-3.0

Try pgrust in your browser →   |   Discord   |   Updates   |   Issues


New: Video of Michael's talk at PlanetScale on pgrust — and the slides.

How AI Changes the Economics of JIT Compilers

What's new in v0.3.

pgrust is a re-implementation of Postgres meant to show what Postgres would look like if it was built in 2026. It is wire compatible and even SQL dialect compatible with Postgres. It passes all 46,066 tests in Postgres' regression suite. For the story of why we're building it, see pgrust: rebuilding Postgres in Rust with AI.

Every line is Rust, written to match the behavior of the C implementation. Rust makes it easy to re-architect several core Postgres pieces. pgrust has:

  • A new vectorized push-based, JIT compiled executor
  • A thread based concurrency model
  • A query scheduler designed to keep any individual query from taking down your database
  • A built-in OOM killer that gives pgrust control of what happens when you're running low on memory, greatly reducing the chance of your whole DB being taken down by the OS OOM killer

and many other really awesome pieces. The scheduler and the OOM killer go after two of the four horsemen behind thousands of Postgres outages.

Status

We don't recommend running pgrust in production (yet), but we are successfully running it ourselves internally. Keep Postgres as the source of truth for data you can't afford to lose.

pgrust currently passes the Postgres regression suite. It's faster than Postgres and ClickHouse, but it still has a lot of bugs. Our #1 priority right now is testing and reliability.

If you need production ready Postgres today, use Postgres.

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.

pgrust is specifically tuned for Graviton4 and the JIT compiler only targets Graviton4. pgrust will still work on other platforms, but will not have similar performance.

Performance

Measured on c8g.4xlarge (AWS Graviton4) against PostgreSQL 18.3.

On the ClickBench combined score, pgrust scored 18.5% faster than ClickHouse and hundreds of times faster than PostgreSQL. This was using pgrcolumnar, pgrust's builtin columnar layout.

On sysbench-oltp, pgrust achieved 30% higher throughput than Postgres 18.3 on read-only workloads at 300GB scale.

For a code-level walkthrough of one part of that speedup, read Rebuilding Postgres for 300x faster analytics: batching, operator fusion, and SIMD.

These runs were reviewed independently by Greg Smith, author of PostgreSQL 9.0 High Performance.

Two honest caveats. We had previously reported that pgrust was over 50% faster than Postgres. On Kubernetes we measure a larger OLTP gap, 50-60% rather than 30%, and we have not isolated why the same binaries behave differently there than on bare EC2, so we quote the lower number. Second, the binaries we publish are generic for their architecture. The benchmark numbers come from builds tuned for Graviton4 (-Ctarget-cpu=neoverse-v2), so you will not reproduce them exactly from a download.

Benchmarks and durability settings are unchanged from a default install: fsync is on. The harnesses are in benchmarks/ so you can run them yourself.

Writing

Testing

The most common question we get about pgrust is: how can anyone trust it? Just because we passed the test suite doesn't mean our code is correct. Getting to the point where people can trust pgrust is our number one priority today. (Getting the regression suite to pass at all took three failed attempts; we wrote up the dead ends in Postgres in Rust: getting the regression suite to pass.)

To achieve that goal, we're taking several different approaches:

  1. Of the 3000 user facing Postgres functions, we've been able to formally verify 1000 of them have identical behavior in pgrust with Kani. In the process of doing so we found 12 divergences between pgrust and Postgres. Four of those were bugs in Postgres itself. See proofs/.
  2. We're engaging with Antithesis to do simulation testing of pgrust to battle test pgrust.
  3. We're doing aggressive differential fuzz testing to ensure pgrust's behavior is identical to Postgres's.

Conformance suite

The regression suite we run 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 (scripts/pg-regress-fast.sh; gate: every one of the 231 parallel_schedule files passes byte-for-byte against the vendor expected output). Prerequisites, the exact local and CI cluster commands, what the harness counts (files vs lines vs queries), and what can and cannot be said about the "46,066" figure are in docs/conformance/README.md; the gate contract is docs/conformance/regress-gate.md.

Unsafe Code

pgrust uses unsafe code, but only for the specific things that need it. Postgres represents every internal value as a Datum, an untyped 8 byte value, and Rust has no safe equivalent, so the code that packs and unpacks internal values is unsafe. The same goes for the places where pgrust must match Postgres' memory layouts byte for byte.

If there are particular unsafes that are not necessary and removing them would not have an impact on performance, let us know, as we would love to remove more unsafes.

Quickstart

In your browser: , a full pgrust server compiled to WebAssembly, no install.

On your machine: pgrust does not ship its own initdb or psql yet, so each flow below installs the PostgreSQL 18 client tools first, then downloads pgrust, then initializes and starts a database. Paste the blocks top to bottom.

macOS (Apple Silicon)

## PostgreSQL 18 client tools (initdb, psql). The formula is keg-only, so
## Homebrew does not put it on your PATH; the export is required.
brew install postgresql@18
export PATH="$(brew --prefix postgresql@18)/bin:$PATH"

## Download pgrust and verify the checksum. Download with curl: curl does not
## set the quarantine flag a browser download gets, so Gatekeeper stays out of
## the way (see the note below).
curl -LO https://pgrust.com/downloads/v0.3/pgrust-0.3-macos-arm64
curl -LO https://pgrust.com/downloads/v0.3/pgrust-0.3-macos-arm64.sha256
shasum -a 256 -c pgrust-0.3-macos-arm64.sha256
chmod +x pgrust-0.3-macos-arm64

## Create a data directory using Postgres' initdb.
initdb -D /tmp/pgrust-data --no-locale --encoding UTF8 -U postgres

## pgrust reads the timezone database and other data

readme truncated — read the full docs on github

Frequently asked questions

Is pgrust free to use?

pgrust is open source under the AGPL-3.0 licence. There is no licence fee and no seat count — you can self-host it or, where the project offers one, pay a vendor for a managed version instead.

What does pgrust do?

Postgres rewritten in Rust, now faster than Postgres and Clickhouse

What is pgrust written in?

pgrust is primarily written in Rust. Its source is publicly available at https://github.com/malisper/pgrust, and it has 5,072 GitHub stars.