Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

Original Article ↗ Hacker News Discussion ↗

A project that uses large language models to rewrite PostgreSQL’s C codebase into Rust and now passes 100% of PostgreSQL’s regression tests is prompting debate over what that actually proves. Commenters weigh the potential benefits—memory safety, new threading architecture, and claimed performance gains—against serious concerns about untested edge cases, reliance on existing test suites instead of “production scars,” readability of LLM-generated code, and long-term maintainability. Licensing choices (AGPL on top of a permissively licensed original) and the broader trend of “rewrite it in Rust with AI” also raise questions about trust, community adoption, and the future of open-source development.

AI vs. “Real” Rewrites

  • Many want a clear distinction between AI-driven rewrites and human rewrites; others argue quality and verification matter more than authorship.
  • Some see “rewrite in Rust using LLMs” as a meme or vibe project, often done fast by a single person with no long‑term maintenance plan.
  • Others view this as an important proof-of-concept showing how cheap large-scale language ports have become, potentially enabling modernization (e.g., COBOL-era systems).

Tests, Reliability, and “Production Scars”

  • Passing 100% of Postgres’ regression tests is considered impressive, but many stress that this only proves absence of known regressions.
  • Repeated concerns:
    • Real reliability comes from years of production incidents and “scar tissue,” not just tests.
    • Tests don’t cover every success path, concurrency edge case, or performance corner.
    • Overfitting to tests is possible, especially for LLMs.
  • Some suggest differential testing (run both DBs and compare outputs), property-based testing, fuzzing, Jepsen-style tests, and mining bug reports into new tests.

Rust, Memory Safety, and Performance

  • Supporters: Rust’s safety model and a thread‑per‑connection architecture could simplify internals, reduce shared-memory complexity, and unlock better parallelism.
  • Critics: There are thousands of unsafe usages (parser especially), so many C-style risks remain; some ask “why Rust at all” if it’s this unsafe.
  • Project author claims:
    • Current published version is ~8× slower than Postgres.
    • A new, unreleased version is ~50% faster on transactional workloads and ~300× faster on analytic workloads, with columnar storage and batch execution, ~2× slower than ClickHouse on clickbench.

Licensing and Legality

  • The port is AGPL; some dislike moving from a permissive Postgres license to copyleft.
  • Debate whether LLM‑generated translations are derivative works, new works, or even copyrightable at all; consensus in thread is “legally murky,” but permissive upstream likely allows more restrictive wrapping.

Maintenance, Trust, and Use in Production

  • Many see this as an interesting experiment or learning tool, not something to run in production “for years” yet.
  • Concerns about:
    • Single‑author bus factor.
    • Reviewability of thousands of AI‑generated commits.
    • Long‑term community, extension ecosystem, and backwards‑compatible upgrades.
  • Some propose a positive use: run such rewrites against real workloads to discover missing tests and feed improvements back to upstream Postgres.