pgrust passed every Postgres test. The tests are not the spec.

TL;DR. pgrust is a Postgres rewrite in Rust, built in under three months, largely by AI coding agents, by one developer with deep Postgres history. In early July 2026 it passed all 46,066 queries in the Postgres 18.3 regression suite. Within days, SQLsmith found crashes and a GitHub issue measured pgbench at roughly one ninth of stock Postgres throughput. Three weeks later, v0.2 reported 30 percent faster OLTP than Postgres 18.3 and a ClickBench score 18.5 percent ahead of ClickHouse. Every one of those headlines is about a different layer of the word compatible: wire protocol, SQL semantics, disk format, performance envelope, operational surface. The regression suite only ever measured one of the five. That gap, between passing the checks and being the thing, is the most useful lesson in the whole story, and it applies to every piece of software an AI agent writes against a test suite.

In April 2026, Michael Malis started what he describes as a two-week experiment: point AI coding agents at PostgreSQL's C source and port it to Rust. Malis is not a tourist here. He spent three years at Heap as the person responsible for a Postgres cluster holding over a petabyte of data, and he has written some of the most-read articles on Postgres internals. By early July, pgrust passed all 46,066 queries in the Postgres 18.3 regression suite. The repository README calls it a re-implementation of Postgres meant to show what Postgres would look like if it was built in 2026.

Then the story turned into a natural experiment on what test suites prove. Andreas Seltenreich, author of the SQLsmith fuzzer that has found many bugs in Postgres itself, started fuzzing pgrust on July 9 and found crashes within days. On July 11, a GitHub issue measured pgbench at about 728 transactions per second against 6,365 for vanilla Postgres 18.4 on the same small machine, with data loading nearly 11 times slower. Three weeks after that, the v0.2 release inverted the performance verdict: 30 percent higher throughput than Postgres 18.3 on read-only sysbench at 300 GB scale, and a ClickBench combined score 18.5 percent faster than ClickHouse. On August 8, Malis published the mechanism writeup: a vectorized push-based executor, JIT compilation that emits machine code in microseconds, and a dictionary-encoded columnar format called pgrcolumnar.

Each wave of headlines tested a different meaning of the word compatible. Laid end to end, they calibrate exactly what each kind of evidence is worth, which matters well beyond this one project, because every "Postgres-compatible" product you evaluate is making a subset of the same five claims.

Three weeks, three verdicts

None of these results contradicts another. That is the point. A system can pass every regression test while segfaulting under a fuzzer and running nine times slower than the original, because the regression suite never claimed to measure crash robustness or speed.

A regression suite is a sample, not a specification

Postgres's regression suite exists to catch regressions in development, and it is engineered to finish fast. Fuzzing, performance testing, and long-haul reliability work are separate practices in the Postgres community, run by people, over decades. The suite is a sample of expected behavior, dense where contributors have been burned before and absent everywhere else.

So when the port passed 100 percent of it, what had actually been demonstrated was narrower than the headline: for these 46,066 queries, pgrust returns the answers Postgres returns. What had not been demonstrated was everything the suite does not encode. Crash recovery under adversarial input. Behavior under concurrency and memory pressure. The performance envelope. The suite has no opinion on any of it, which is why SQLsmith needed only days to mark its edge, and why a 9x pgbench gap could coexist with a perfect score.

The follow-up is what makes pgrust interesting rather than merely cautionary. The project treated each falsified layer as a work item, not a refutation. Three weeks later the performance layer had flipped, with the receipts published: benchmarks on an AWS c8g.4xlarge, defaults left in place with fsync enabled on both systems, scripts in the repository, and the setup reviewed by Greg Smith, whose book on Postgres performance is a standard reference. The caveats are published too. The JIT targets Graviton4 specifically, the published generic binaries are not tuned that way, and the columnar numbers come from pgrcolumnar, a new storage format, not from the row store your OLTP tables would use.

Compatible is five claims, not one

Five separate claims hide inside one word. The regression suite tests exactly one of them.

Every product that says "Postgres-compatible" is asserting some subset of five distinct claims, and it pays to ask which:

• Wire protocol. Existing drivers and clients connect. Nearly everyone claims this layer; it is the cheapest.
• SQL semantics. The same queries produce the same answers. This is the layer the regression suite measures, and most compatible databases pass a curated subset rather than all of it.
• Disk format. The engine can read existing data files in place. pgrust, per the project, boots from an unmodified Postgres 18.3 data directory. Almost nobody else claims this layer.
• Performance envelope. The same workload lands in the same order of magnitude, in both directions: a system that is 300x faster on scans and 9x slower on writes is not in your envelope until both numbers work.
• Operational surface. Extensions load, tooling works, replication and backup behave, and the failure modes are the ones three decades of production have already found. This is the layer no rewrite can pass quickly, because it is not code. It is accumulated evidence.

Read AWS Aurora against this list and it claims wire, semantics, and operations while replacing the storage engine underneath. CockroachDB claims wire and a documented subset of semantics. Neon runs genuine Postgres compute over its own storage, which is why its compatibility story is strong everywhere except the storage-dependent corners, an architecture we took apart when Databricks built Lakebase on it. pgrust's claim set is unusually deep, wire plus full-suite semantics plus disk, and the project is candid that the operational layer is simply not there: existing extensions do not work, there is no stable extension ABI, the procedural languages beyond PL/pgSQL are not ported, and the README says, in so many words, do not put data you care about in it.

That last layer is where adoption is decided, and it is worth being precise about why. A team choosing a database is not buying query answers. It is buying the absence of surprises: the pg_stat views its runbooks parse, the extension its search feature depends on, the known shape of a vacuum stall at 3 a.m. Those are properties of an ecosystem and a history, not of an engine, which is why they are the one thing a three-month rewrite cannot port. This is not a criticism of pgrust. It is a description of what kind of object pgrust currently is: a research result of real quality, not a database you run.

The analytics numbers are the HTAP argument arriving at a single node

The v0.2 architecture is worth reading on its own terms, because it is the hybrid-workload argument compressed into one process. A vectorized, JIT-compiled executor over a columnar format for scans. A row path that stays 30 percent ahead of stock Postgres on read-heavy OLTP. And, notably, a query scheduler that adjusts priorities so a heavy analytical query cannot starve fast transactional ones, plus a built-in OOM killer, which together are an attempt to answer in-engine the question that usually kills one-box hybrid setups: not whether scans are fast, but whether the two workloads can share a machine without the analytical one eating the transactional one's latency. When we measured the OLTP, OLAP, and HTAP boundary, isolation, not scan speed, was the property that separated systems that work from demos. A scheduler is a real answer to that question. Whether it holds under production concurrency is exactly the kind of claim that lives on the operational layer, where pgrust has not yet earned evidence.

The lesson for software written by agents

The methodology, per Malis's own writeup, was to convert the C source to unsafe Rust with c2rust, then rebuild it crate by crate into safe Rust using coding agents, primarily OpenAI's Codex, at points running 17 of them concurrently. The regression suite was the target the agents worked against.

Look at what that produced. Every property the suite encoded got built, to a 100 percent pass. Every property the suite did not encode, crash robustness under fuzzing, the performance envelope, was initially absent, and had to be added by a human-directed loop afterward: triaging SQLsmith crashes, profiling pgbench, rebuilding the executor. The suite functioned as the specification the agents optimized, and the delivered system was, with high fidelity, exactly what the suite asked for. No more.

That is the durable lesson, and it has nothing specific to do with databases. A test suite is a sample of intended behavior, and an agent optimizing against it will converge on the sample, not the intent. pgrust's roadmap concedes the point in the most concrete way possible: the stated next phase is testing and reliability, formal verification with Kani, simulation testing with Antithesis, which is to say, better specifications, because the checks define the deliverable. We made a structurally identical argument about Apache Ossie: a definition travels between systems, and everything that makes the definition trustworthy does not travel with it. Here, behavior transferred at 100 percent fidelity, and assurance did not transfer at all, because assurance was never in the artifact being copied. Teams already know a version of this from their own pipelines: a migration that passes every check on a staging copy can still take down production, because the checks sampled the data, not the workload. As more of the code that touches your databases is written by agents against whatever checks you happen to have, the coverage of those checks quietly becomes your real specification. It is worth asking what yours currently encode, and what they leave to luck.

Where Datapace fits

Datapace is building the context layer between your databases and your AI: resolved meaning validated by the people who own the data, the workload evidence beside it (cost, performance, usage and freshness, lineage), and a policy gate over what an agent may do and access, served over MCP. The pgrust story is the same boundary drawn inside an engine: what an agent can verify is only ever what its checks encode, and the checks are where the real spec lives. If your team is working out what agents should be allowed to do against production data, start with the measured OLTP, OLAP, and HTAP comparison, or book a call.

Sources

1. Michael Malis, "Rebuilding Postgres for 300x faster analytics: batching, operator fusion, and SIMD", August 8, 2026.
2. Michael Malis, "pgrust: Rebuilding Postgres in Rust with AI", July 2026.
3. pgrust repository and README, and pgrust v0.2 release notes, July 30, 2026.
4. pgrust issue #31: pgbench performance vs vanilla Postgres, July 11, 2026.
5. lilting.ch, "pgrust passed 100% of Postgres regression tests: SQLsmith segfaulted it in days", 2026.
6. Vonng, "Did AI Rewrite PostgreSQL in Rust? Not Quite", 2026.
7. Hacker News discussion of the regression-suite milestone, July 2026.