What people locked onto was not whether the headline milestone is neat. It clearly is. The real question was what passing the
regression suite actually buys you for a database. The consensus was blunt: it proves useful compatibility, not real trustworthiness. Postgres’s tests carry years of production scars, so passing them is meaningful. But a rewrite also creates new failure modes in concurrency, durability,
crash recovery, filesystem behavior, and weird success cases that never broke in upstream and therefore may not be explicitly tested. That is why multiple people pushed for
Jepsen-style validation,
fuzzing, property-based
differential testing against upstream Postgres, and mirrored production traffic before anyone should take performance claims or safety claims too seriously.
A second thread sharpened the technical substance behind the speed claims. The author said the big gains come from architecture changes rather than Rust alone: threads instead of processes, shared address space for parallel operators, batching, prefetching,
vectorized execution, and columnar storage. That matched how others framed modern
OLAP systems like ClickHouse. Several commenters still challenged whether threads themselves are the magic ingredient, noting PostgreSQL can share memory across processes and that moving from process-per-connection is as much a development simplification as a raw performance unlock. The stronger takeaway was narrower. If the rewrite becomes interesting, it will be because it uses Postgres compatibility as a launchpad for a different engine design, not because C became Rust.
The mood around AI coding was skeptical to hostile. People did not object to translation work in principle. Many accepted that rewrites are exactly the kind of grunt work LLMs can accelerate. What they rejected was the idea that thousands of machine-generated commits and a passing test suite add up to maintainability or understanding. Several argued that for AI-heavy codebases, review shifts away from line-by-line commit history and toward architecture, contracts, test oracles, fuzzing, and formal validation for the critical pieces. That landed as the most practical frame in the whole conversation. If code generation gets cheaper, confidence has to come from stronger evaluation and from keeping humans focused on the small set of components where wrong means corruption or data loss.
There were also two narrower but important caveats. First, much of the visible
unsafe Rust is concentrated in the parser, which the author mechanically ported from PostgreSQL’s
yacc and
bison generated parser through c2rust rather than rewriting by hand. That softened some of the alarm about raw pointer usage, but not the broader complaint that a Rust port only cashes in on memory safety if the dangerous edges are truly reduced. Second, extension compatibility is a major obstacle. PostgreSQL extensions reach deep into internals and do not sit on a clean stable API, so a compatible ecosystem would require either
ABI fidelity to C internals or extensive rewrites. That alone keeps this far from being a drop-in replacement.
So the conversation ended in a pretty clear place. As a proof that AI-assisted translation plus an old and battle-tested test suite can move a monster codebase surprisingly far, this is impressive. As a database anyone should trust with production data, it has not crossed the line yet. The next decisive evidence is not another benchmark chart. It is unseen-input testing, crash and isolation validation, upgrade and compatibility stories, and proof that the project can survive the boring maintenance phase after the demo wow factor fades.
github.com