編按：本文綜合整理自 GitHub: malisper/pgrust、Hacker News 討論串、malisper 部落格四月原文、五月 67% 進度更新、Four Horsemen roadmap 文章、Reddit r/rust 討論，並加入 Siami 編輯部觀點與分析。
從 34% 到 100%：三個月衝過 Postgres 4 萬 6 千條回歸測試
GitHub 上的開源專案 pgrust（malisper/pgrust）宣佈，該專案已通過 Postgres 18.3 的 100% 回歸測試（46,000 多條 SQL 查詢）。這個專案的目標極其大膽：從零用 Rust 完整重寫一套 PostgreSQL 相容的資料庫，並且做到 磁碟格式相容 —— 可以直接從現有的 Postgres 18.3 資料目錄開機。
pgrust 不是玩具級 clone，而是要成為「Postgres 行為的近親」，讓開發者可以用 Rust + AI 工具對伺服器內部做更深層的改造。根據專案 README，這次里程碑代表的不只是測試通過率，而是驗證了 「以原生 Postgres 回歸測試套件作為 oracle」這條開發路徑的可行性。
「The goal is to make Postgres easier to change from the inside: keep the behavior Postgres-shaped, keep the real Postgres tests as the oracle, and use Rust plus AI-assisted programming to explore deeper server changes.」 — pgrust README
這個專案自四月首次亮相時僅通過 34% 測試，五月已經衝到 67%，六月底達到 96%，七月正式宣布 100%。這條加速曲線在開源資料庫專案史上極為罕見。
「8 個 Codex 帳號 + git worktree」的工廠式開發
這次衝刺背後的工作方式，才是讓開發圈真正興奮（也真正擔憂）的部分。專案作者 malisper 在部落格文章中詳細揭露了他的工作流：
- 平行運作 8 個 OpenAI Codex 帳號，每個帳號每月 $200，等於每月燒掉 $1,600 美金在 AI tokens
- 每個 agent 在自己的 git worktree 裡獨立作業，避免互相踩到
- 兩週內 merge 了 280 個 PR
- 整個程式碼庫已膨脹到 45 萬行 Rust
- MacBook Pro 14 CPU 經常跑滿 80–100%，他自己形容為「在玩 Factorio」
他提到一個關鍵的優化發現：原本 SQL parser 的編譯時間佔掉整個 build 的一半。把生成的 grammar 程式碼拆成獨立 compilation unit 之後，重新編譯其餘部分從 60 秒降到 36 秒 —— 這個數字乘上「每個 agent 每次跑測試」之後，就決定了能同時跑幾個 agent。
「My role in building pgrust has become less about hand writing code and more about designing a system that produces the output I want, then optimizing that system to move faster.」 — malisper，四月原文
這段話幾乎宣告了 AI 時代「資深工程師」角色的轉變：不再是直接寫程式碼的人，而是設計、調校、debug 一個會自動產出程式碼的系統。
不只是「重寫 C 到 Rust」：磁碟相容 + WASM 瀏覽器 demo
pgrust 跟之前幾個「用 Rust 重寫 Postgres」的嘗試有兩個關鍵差別：
- 磁碟格式相容：可以開機自現有的 Postgres 18.3 資料目錄，這代表企業不必 migrate 資料就能試用
- 編譯成 WebAssembly，在瀏覽器直接跑：官方 demo 站 pgrust.com 讓你開瀏覽器就能執行 SQL，甚至預載了一個 Lisp 解譯器的範例
不過專案也明說目前還不適合生產環境：尚未效能最佳化、PL/Python、PL/Perl、PL/Tcl 等 procedural language 還沒相容、多執行緒還在 roadmap。Docker 映像（malisper/pgrust:v0.1）已經能跑起來，但定位仍是實驗性質。
🚨 為什麼這件事重要
這篇文章的真正意義不在「pgrust 能不能取代 PostgreSQL」，而是在展示 「AI + Rust 重寫既有 C 語言大型系統」這條生產線已經被驗證可行。
過去十年開源社群對「用 Rust 重寫 C」的態度一直很兩極：diesel、sqlx、sled、Tauri 這些專案成功了，但更大規模的（像伺服器、作業系統、資料庫核心）都卡在「人手不夠」或「沒有跟原專案同步演進」。pgrust 用了一個極具破壞性的方法繞過這個問題：把「能不能跟原版同步」外包給 AI，用原版的 regression test 當 oracle、用 Codex 當勞動力、用 git worktree 當產線。
這對整個開源生態有三個直接影響：
- Postgres 本身可能會被倒逼改進：pgrust 公開列出「Four Horsemen」（造成上千次 Postgres 當機的四個元凶）作為優先要解決的問題，這份 roadmap 可能成為 Postgres 上游的壓力來源
- 「付費給多個 AI 帳號」會變成新工作流：8 個 Codex Pro 帳號 $1,600/月，這個成本結構對個人開發者是天文數字，但對企業 R&D 部門根本是零頭。如果這種工作流被證明有效，會快速擴散
- 「資深工程師」的工作內容會從「寫程式碼」轉向「設計 AI 工廠」：malisper 自己說得很清楚，他的工作不再是 hand-writing code，而是 tuning the system
當然，這一切的前提是 AI 寫出來的程式碼品質要過得了嚴格迴歸測試 —— 這正是 pgrust 聲稱已經做到的。
🚨 數據解讀 / 質疑
雖然 100% 通過 regression test 是個漂亮的數字，但魔鬼藏在細節裡：
- regression test 通過 ≠ 效能達標：README 明確寫「not performance optimized yet」。一個 Postgres C 實作經過 30 年效能調校，Rust 重新實作要做到同等 TPS 是另外一個量級的工作
- 100% 是「Postgres 18.3 snapshot」的測試：Postgres 上游每季都出新版本（下次 8 月 13 日），pgrust 要長期 maintain 這個 100% 等於要跟著 upstream 跑，這對一人 + AI 專案是巨大負荷
- AI 程式碼的可審計性問題：Hacker News 上有不少質疑聲音，擔心 280 個 PR 在兩週內 merge、其中多少是「code fully generated by AI, possibly not fully reviewed by human eyes」。對比 Bun 上個月 Rust rewrite 被 miri 抓到 undefined behavior 的事件，這類疑慮並非無的放矢
- 磁碟相容不等於 wire protocol 相容：Postgres 的 ecosystem 很大一部分是 extensions（PostGIS、TimescaleDB、pgvector 等），這些都還沒處理。企業真要用，等於放棄整個 extension 生態
最關鍵的問題是： pgrust 要證明的不只是「AI 能重寫」，而是「AI 重寫的東西能 maintain」。一年後再來看這個專案是否還保持 100%、是否還跟著 Postgres 上游演進，那才是真正的答案。
開發者後續可關注的指標
對想持續追蹤這個專案的人，幾個值得看的訊號：
- GitHub commit 頻率：從 280 PR / 兩週到 100 PR / 兩週，能看出是「高速撞牆期」還是「穩定維護期」
- 效能 benchmark：作者尚未釋出任何 vs 上游 Postgres 的 TPS 數字。一旦有，就是大新聞
- 是否開始 port extension：PostGIS 或 pgvector 任何一個能跑，就代表 PL/Python 那條路線通了
- 是否吸引企業 sponsor：AGPL-3.0 對企業友善度有限，看 Supabase、Crunchy Data、AWS 是否會有人投入
- Hacker News 後續討論串：這次上首頁拿了 378 分（48 小時內），比五月那篇 96% 的文章熱度更高，代表社群關注度正在上升
對 Rust 社群而言，pgrust 是 「能不能用 AI + Rust 重寫大型 C 專案」這個母題的最新一筆資料。對 AI 工具供應商（OpenAI、Anthropic）而言，這則是 「AI coding agent 在真實大型 codebase 上的能耐」 的具體展示。兩個圈子都在等下一輪數字。
網友熱門留言 (4)