On July 9, 2026, Malcolm Matis — former CEO of Heap and a long-time Postgres practitioner — announced something that would have sounded like satire eighteen months ago: a complete rewrite of PostgreSQL in Rust, largely generated by eight AI coding agents, that passes all 46,066 queries in the PostgreSQL 18.3 regression suite.
Not a subset. Not "most of them." The entire suite, without a single failure.
The project is called pgrust, it is AGPL-3.0 licensed, and it has become the most concrete data point yet in an argument developers have been having all year: can AI agents actually do serious systems work, or do they just produce plausible-looking code that collapses on contact with reality?
The honest answer, as usual, is somewhere in the middle — and the details matter a great deal.
What was actually built
The numbers are worth stating plainly:
| Metric | Value |
|---|---|
| Lines of Rust generated | 450,000+ |
| Parallel AI agents | 8 (paid Codex accounts) |
| Tooling for coordination | Conductor, 10–20 parallel sessions |
| Monthly agent cost | ~$1,600 |
| Regression queries passed | 46,066 / 46,066 |
| Time to first working build | Roughly three months |
That last row deserves attention. PostgreSQL represents roughly three decades of accumulated engineering. A small team with an agent fleet reproduced its externally observable behaviour in a different language in a single quarter, for less than the monthly cost of one junior engineer.
The v0.1 release is not a toy. It speaks the native Postgres wire protocol, so psql and standard client drivers connect to it without modification. It boots directly from an existing PostgreSQL 18.3 data directory — no dump, no migration, no conversion step. It runs a real query planner: EXPLAIN ANALYZE works, and it makes genuine index-versus-sequential-scan decisions rather than faking the output.
You can try it in about thirty seconds:
docker pull malisper/pgrust:v0.1
docker run -d --name pgrust-demo -e POSTGRES_PASSWORD=secret malisper/pgrust:v0.1
docker exec -it pgrust-demo psql -U postgres -h 127.0.0.1There is also a browser-based WebAssembly demo at pgrust.com if you would rather not pull an image.
The architectural bet
Here is where pgrust stops being a translation exercise and starts being an actual engineering argument.
PostgreSQL uses a process-per-connection model. Every client connection forks a new OS process. This is why PostgreSQL is famously memory-hungry under high connection counts, and why virtually every production deployment sits behind PgBouncer or a similar pooler. The design dates to an era when threads were unreliable and process isolation was the sane default.
The v0.1 release preserves this model — sensibly, since the goal was compatibility first. But the unreleased development branch shifts to thread-per-connection: the database runs as a single process, connections become lightweight threads, and memory is shared rather than duplicated. That unlocks shared caches across connections and substantially reduces the need for external pooling.
The claimed results from that branch:
- 50% faster transactional throughput on Percona-TPCC
- ~300x faster on analytical workloads
- 10x faster regex operations
- Still 2x slower than ClickHouse on ClickBench
Treat every one of those figures as directional. They come from an unreleased codebase and have not been independently reproduced. Matis himself is careful to describe v0.1 as neither production-ready nor performance-optimized.
The 300x analytical figure in particular is less magical than it sounds. PostgreSQL's row-store execution engine was never designed for analytical scans, and beating it on that axis is a known, well-understood win. The ClickBench result — still half ClickHouse's speed — is the more informative number, because it shows pgrust landing in a reasonable place relative to a purpose-built columnar engine rather than in fantasy territory.
What doesn't work
The extension ecosystem is the wall.
pgvector, TimescaleDB, PostGIS — none of them work. And for an enormous fraction of real PostgreSQL deployments in 2026, that is the entire reason PostgreSQL was chosen. A Postgres without pgvector is not a drop-in replacement for a team building retrieval-augmented generation; it is a different product that happens to speak the same wire protocol.
This is not an incidental gap. PostgreSQL extensions link against internal C APIs, memory contexts, and function-pointer tables that have no natural Rust equivalent. Supporting them means either reimplementing each extension in Rust or building an FFI compatibility shim that reintroduces much of the unsafety Rust was adopted to eliminate. Neither is a weekend project.
The thread-per-connection model also carries a real cost that the benchmark table does not show. Under process isolation, a segfault in one backend kills one connection. Under a shared-memory thread model, memory corruption in one thread can take down every connection on the instance. Rust's guarantees help substantially here — but unsafe blocks exist in any database that touches raw pages, and this codebase has 450,000 lines of them to audit.
The part that should actually change your thinking
It is tempting to file this under "impressive demo, ignore until v2." That would be a mistake, but so would the opposite reaction.
The genuinely significant claim is not that AI wrote a database. It is that a comprehensive test suite turned out to be a sufficient specification for a machine to reimplement a system against. PostgreSQL's regression suite is the accumulated paranoia of thirty years of maintainers writing down every edge case that ever bit them. That corpus, it turns out, is dense enough to steer an agent fleet toward behavioural equivalence.
That has a direct implication for your own codebase, and it is not the one most people reach for first. It is not "we can rewrite our legacy system now." It is: the quality of your test suite now determines whether AI-assisted migration is even available to you as an option. A system with thin tests cannot be safely rewritten by agents, because nothing constrains the output. A system with an exhaustive behavioural suite can be. Test coverage has quietly become a migration capability, not just a defect-prevention tactic.
The counterweight is equally important. Passing 46,066 regression queries is not the same as being correct. Production databases fail in ways test suites structurally cannot capture: replication lag under partition, WAL corruption after power loss, planner regressions that only appear at a particular table statistics distribution, lock contention patterns that emerge at a thousand concurrent writers. PostgreSQL's reliability comes from three decades of that exposure, not from its test files. Reproducing the tests reproduces the specification, not the hardening.
The skeptics are right about this, and they are right in a way that does not diminish the achievement.
Should you do anything about this?
For production workloads, the answer is no, and it will remain no for some time. Nobody should be considering pgrust for anything holding real data in 2026.
But there are three things worth doing:
Run the Docker image. Point it at a copy of a real data directory and run your actual query workload against it. Thirty minutes of hands-on experience is worth more than any blog post, including this one, for calibrating how far this technology has come.
Audit your test suite as a migration asset. Ask a concrete question: if you handed your test suite and nothing else to a competent engineer who had never seen your code, could they reimplement the system? Wherever the answer is no, that is exactly where AI-assisted modernization is unavailable to you — and where the gap is worth closing regardless.
Recalibrate scope estimates, carefully. The old intuition that a systems-level rewrite is a multi-year, multi-team commitment is now unreliable for the code generation portion of the work. It remains entirely reliable for validation, hardening, and production trust — which, as pgrust demonstrates, is where the overwhelming majority of the real cost has always lived.
The uncomfortable synthesis
Both of the popular readings of pgrust are wrong.
"AI can now rewrite anything" is wrong because the extension gap, the unverified benchmarks, and the absent production hardening are not minor todos — they are the majority of the remaining work, and they are the hard part.
"This is just a demo with no substance" is also wrong, because 46,066 passing regression queries against a thirty-year-old codebase is not something the industry could produce at this cost six months ago, and pretending otherwise is a failure of observation.
What actually changed is the ratio. Writing the code is no longer the expensive part of a large migration. Knowing whether the code is right still is — and the teams that invested in knowing that, through tests, observability, and specification discipline, are the ones who just gained a genuinely new capability.
At Noqta, that is the lens we apply to modernization work: the migration is rarely blocked by the volume of code. It is blocked by not being able to prove the new thing behaves like the old thing. pgrust is the clearest demonstration yet of what becomes possible once that proof exists — and of how much work remains after it does.
Related reading: