🦀 The claim, and the test 0:00
The opening does something most tool coverage does not: it states the headline and immediately withdraws the obvious conclusion.
The diagnosis of why anyone would attempt this is fair. Postgres carries nearly four decades of architecture and roughly a million lines of C. Every client connection gets its own backend process — isolation that is genuinely useful, and that also means memory overhead per connection, pressure toward external pooling, and difficulty sharing state across parallel work.
pgrust's premise is narrow and unusual: keep the behaviour, keep the client experience, keep the on-disk formats, replace the engine. Not a fork, not an extension — an independent implementation that treats real Postgres as the specification.
malisper/pgrust — 3,912 stars, 147 forks, Rust, AGPL-3.0, created 20 April 2026 and pushed to the day I wrote this. The README's own badges claim 46,066/46,066 regression tests and Postgres 18.3 compatibility.✅ What 46,066 tests prove 2:45
The demo is straightforward and the presenter does not oversell it: official Docker image, an ordinary psql client, create a table, insert data, run EXPLAIN. The planner chooses an index scan and returns real execution statistics. From the outside it is indistinguishable from Postgres.
His summary of what that establishes is the correct one:
And the counterweight, which the video also supplies rather than leaving to the comments:
That distinction — known tests versus untested situations — is the whole argument about database trust compressed into two sentences, and it is the part worth carrying regardless of what happens to this project.
⏳ The caveat that expired 5:00
The video's structural caution is that everything interesting is out of reach:
That was accurate on 17 July. It is not accurate now, and the gap is only thirteen days.
v0.2, and the thread model shipped. The README's "What's new in v0.2" lists "Threads instead of processes, for both connections and parallel query" as a released feature, alongside a vectorized push-based JIT-compiled executor, a query scheduler, work-stealing parallel query, a columnar storage format (pgrcolumnar), pipelined fsync, and a built-in OOM killer. The benchmark harnesses are published in benchmarks/ so the numbers can be reproduced, and there is a full server compiled to WebAssembly running in the browser at pgrust.com.📉 The numbers moved down 5:37
The video reports the developers' claims as roughly 50% better on transactional workloads and around 300× Postgres on analytical workloads, and treats them as unverifiable promises. The published numbers are different, and the direction of the difference is the interesting part.
| Claim in the video | What the README says today |
|---|---|
| ~50% faster, transactional | 30% higher throughput on sysbench-oltp read-only at 300GB scale |
| ~300× Postgres, analytical | "Hundreds of times faster" on ClickBench — and 18.5% faster than ClickHouse |
| Numbers unverifiable | Harnesses published in benchmarks/; reviewed independently by Greg Smith, author of PostgreSQL 9.0 High Performance |
The revision is not something a reader had to catch — the maintainers flag it themselves, in a passage headed "two honest caveats":
Also worth separating: "hundreds of times faster than PostgreSQL" on ClickBench is a comparison against a row-store doing analytical work, which is not what Postgres is for. The meaningful figure in that row is 18.5% faster than ClickHouse — a purpose-built columnar engine. That is the claim that would be impressive if it holds, and the one the "300×" headline obscures.
🔬 Four bugs in Postgres 6:52
The video asks the right question — how could anyone trust this? — and answers it with a fair generality about crash recovery and years of production. The README answers it with a testing programme the video does not mention, and one item in it is genuinely remarkable.
The maintainers are also candid about how hard the headline achievement was: getting the regression suite to pass took three failed attempts, and they wrote up the dead ends publicly. That is a detail that makes the 46,066 figure more credible, not less.
🧵 Threads, and what they cost 4:18
The best analytical passage in the video, and it refuses the easy conclusion. Thread-per-connection lowers per-connection overhead and makes sharing state between parts of the database easier. But:
That is exactly right, and the shipped design shows the maintainers reached the same conclusion. Two v0.2 features exist specifically to rebuild the safety rails that processes provided for free:
- A query scheduler — queries get a priority, and long-running queries have theirs lowered, so heavy queries interfere less with fast ones. Described as new to Postgres.
- A built-in OOM killer — near the memory limit, pgrust picks a worker to kill so that one query dies instead of the OS killing the whole server.
On memory safety, the README is precise rather than triumphal: pgrust does use unsafe, specifically where Postgres represents every internal value as an untyped 8-byte Datum and where memory layouts must match byte for byte. "Rewritten in Rust" does not mean "no unsafe code", and they say so.
🔌 Why not an extension 3:10
A clean piece of reasoning that generalises well beyond databases. Three options, three different failure modes:
| Approach | Limitation |
|---|---|
| Extension | Sits on top of the original core — cannot change the architecture underneath |
| Fork | Can change the core, but inherits the architecture and the permanent job of tracking upstream |
| Independent DB (CockroachDB, YugabyteDB) | Free to rearchitect, but exact drop-in compatibility is not the goal |
| pgrust | Uses Postgres behaviour as the specification — free to rearchitect while compatibility stays measurable |
The elegance is that the regression suite becomes both the constraint and the scoreboard. You can rebuild the executor however you like as long as 46,066 queries still agree.
🤖 The real experiment is economic 5:05
The video's sharpest reframe, and the reason this belongs in an agents publication rather than a database one:
Michael Malis and Jason Seibel used coding agents heavily. The published release deliberately mirrors the original Postgres structure in many places — which is what makes a differential comparison possible at all — while the architectural changes went into the later work.
The presenter's closing generalisation is the right one: "we don't need to change the entire Postgres project before learning whether an idea actually works. That freedom may be more valuable than any single benchmark."
⚠️ The Graviton4 footnote 6:55
One qualification appears nowhere in the video and materially narrows every performance number quoted above.
c8g.4xlarge, and the published binaries are generic builds — the maintainers state plainly that "you will not reproduce them exactly from a download" because the benchmark builds used -Ctarget-cpu=neoverse-v2.So the honest reading of the headline speed claims is: 30% faster than Postgres and 18.5% faster than ClickHouse, on one AWS instance family, with a build you have to make yourself. That is still a real result, and it is a considerably narrower one than "faster than Postgres and ClickHouse" implies.
Two further constraints worth knowing before trying it: pgrust does not yet ship its own initdb or psql, and the project is not accepting pull requests right now — issues yes, code contributions no.
🏦 Reading this as a bank 7:45
The video's verdict is correct and worth repeating verbatim: "Should you replace your production Postgres cluster with pgrust? No, absolutely not." The project says the same about itself — "Do not put data you care about in it."
For a regulated environment the calculus is even simpler, and three items settle it before performance ever comes up:
| Consideration | Status |
|---|---|
| Maintainers' own production guidance | "Not production ready. Do not put data you care about in it." |
| Licence | AGPL-3.0 — network-use source obligations, unlike Postgres's permissive licence |
| Extension ecosystem | No stable ABI; existing extensions do not work |
| Crash recovery / replication track record | None yet — the thing regression tests cannot substitute for |
| Hardware coupling | Performance story is Graviton4-specific |
| Worth watching | Yes — the verification programme and the trust methodology are the transferable part |
What is genuinely worth borrowing is the trust methodology: an executable oracle (the regression suite), formal verification of a subset of behaviour, differential fuzzing against the reference, and simulation testing. That template applies to any system where you must prove a new implementation matches an old one — a migration pattern most large institutions run repeatedly, and usually with far weaker evidence than this.
🔍 Claims checked
Every checkable claim was verified against the GitHub API and the project's own README rather than the narration:
| Claim | Result |
|---|---|
| Passes all ~46,000 regression queries | Exact figure is 46,066/46,066, stated in the README badge |
Works with a normal psql client, boots a Postgres 18.3 data directory | Wire and SQL dialect compatible; 18.3 is the stated target |
| Written in Rust, real query planner and storage engine | malisper/pgrust, Rust, 3,912 stars, 147 forks |
| Not production ready | Verbatim: "Do not put data you care about in it." |
| Existing extensions don't work | Confirmed — no stable extension ABI; PL/Python, PL/Perl, PL/Tcl not ported |
| Built with heavy use of coding agents | The maintainers' own framing, in a linked write-up |
| The thread-per-connection version is unpublished and untestable | No longer true. Shipped in v0.2, with benchmark harnesses published in benchmarks/ |
| ~50% faster on transactional workloads | Revised down by the maintainers to 30% on sysbench-oltp; they explain why they quote the lower figure |
| ~300× Postgres on analytical workloads | README says "hundreds of times" vs Postgres, and 18.5% vs ClickHouse — the latter is the meaningful comparison |
| Performance is portable | Not stated in the video. Tuned for Graviton4; the JIT targets it exclusively |
| Licence | Not mentioned in the video. AGPL-3.0, versus Postgres's permissive licence |
| Formal verification found bugs in Postgres | Not mentioned in the video. 1,000 functions verified with Kani, 12 divergences, 4 were Postgres bugs |
Repository state, star counts and README contents verified 30 July 2026 against HEAD.
💡 Key takeaways
- 46,066 of 46,066 regression queries pass. Not "Postgres compatible" as a marketing phrase — a measurable target where the real Postgres tests are the judge.
- But passing known tests is not production trust. The video's best line: a project can pass every known test and still fail in a situation nobody thought to test. Crash recovery and replication track records take years, not test runs.
- The video's core caveat expired in thirteen days. The "unpublished, unbenchmarkable" thread-per-connection version shipped in
v0.2, with harnesses published so you can reproduce the numbers. - The maintainers revised their own claims downward. From "over 50% faster" to 30% — because Kubernetes showed 50–60%, EC2 showed 30%, they could not explain the gap, and so they quote the lower one.
- That is the strongest credibility signal in the whole story. Publishing your worst reproducible result, with the reason, beats any multiplier — and stands in sharp contrast to vendor benchmark tables that disagree by 14 points without comment.
- The meaningful analytical number is 18.5% vs ClickHouse, not "hundreds of times vs Postgres". Beating a row-store at columnar work is expected; beating a purpose-built columnar engine is the claim worth testing.
- Formal verification found four bugs in Postgres itself. 1,000 of ~3,000 user-facing functions verified with Kani, 12 divergences found, four of them defects in the forty-year-old original. Reimplementation as a bug-finding technique.
- Threads remove safety rails, and the design admits it. A query scheduler and a built-in OOM killer exist precisely to rebuild what process isolation gave for free.
- Owning the OOM decision is a real improvement. The OS killer has no idea which process matters and can take the whole database down; pgrust kills one query instead.
- "Rewritten in Rust" does not mean no unsafe code. Postgres's untyped 8-byte
Datumand byte-exact memory layouts require it, and the README says so plainly. - Extensions are the commercial gap. No stable ABI, PL/Python, PL/Perl and PL/Tcl unported. For most real deployments the extension ecosystem is Postgres.
- The performance story is Graviton4-specific, and the video never says so. The JIT targets it exclusively; published binaries are generic and will not reproduce the benchmarks.
- The licence changes, and the video never mentions it. Postgres is permissively licensed; pgrust is AGPL-3.0 with network-use obligations. That is a legal decision wearing an infrastructure disguise.
- The real experiment is about cost, not Rust. Can agents make a rewrite this large affordable enough that architecture becomes negotiable? The answer determines which infrastructure experiments are worth attempting at all.
- The transferable lesson is the oracle. AI-generated code is safest where an executable reference exists to disagree with it — 46,066 tests plus differential fuzzing plus formal proofs. That template applies to any migration where you must prove new matches old.
🔗 Resources & links
- Postgres was rewritten in Rust… and somehow passed every testSource video — Better Stack, 8:34, 44,857 views
- malisper/pgrustThe repository — Rust, AGPL-3.0, 3,912 stars. Read the Status and Performance sections before anything else
- pgrust.comA full pgrust server compiled to WebAssembly, running in the browser — no install
- pgrust passes 100% of PostgreSQL's regression testsThe maintainers' write-up of the 46,066 figure
- pgrust: rebuilding Postgres in Rust with AIWhy they built it, and how agents were used
- Getting the regression suite to passThe three failed attempts and the dead ends
- KaniThe Rust model checker used to formally verify 1,000 functions — and find four Postgres bugs