pgrust: 使用 LLM 的 Postgres Rust 重寫版

pgrust 概覽

pgrust 是一個實驗性專案，旨在利用大型語言模型 (LLMs) 加速開發過程，將 PostgreSQL 用 Rust 重寫。該專案旨在現代化資料庫架構，同時保持與原始 PostgreSQL 規範的相容性，目前已通過 100% 的 Postgres 回歸測試。

關鍵架構變更與效能

作者 @malisper 已對資料庫架構進行了幾項根本性的變更，以提升相對於原始 C 語言實作的效能：

• 執行緒模型： pgrust 將 PostgreSQL 使用的傳統「一連線一程序」模型替換為「一連線一執行緒」模型。
• 交易工作負載： 該專案報告稱，在交易密集型工作負載下，效能比 PostgreSQL 提升了 50%。
• 分析型工作負載： pgrust 聲稱在分析型工作負載上比 PostgreSQL 快約 300 倍，儘管在 Clickbench 基準測試中仍比 Clickhouse 慢約 2 倍。

技術評論與安全性疑慮

儘管有這些效能聲稱，該專案在生成程式碼的安全性與品質方面，受到了技術社群的顯著審查。

使用 Unsafe Rust

審查人員提出的主要疑慮之一是大量使用了 unsafe 區塊。對程式碼庫的分析顯示，共有 2,664 個 unsafe { 實例和 1,835 個 unsafe fn，這導致一些批評者認為，該專案是一個「大量使用原始指標的 AI 生成轉譯版」，而非利用 Rust 記憶體安全保證的重新設計。

可靠性 vs. 測試覆蓋率

社群成員強調了「通過測試套件」與「達到生產環境就緒」之間的區別。批評者認為，PostgreSQL 的可靠性源於數十年的「真實世界生產環境傷痕」，而非僅僅是回歸測試。此外，有人指出，標準的 Postgres 回歸測試並未針對新的執行緒架構進行專門驗證，這是一個潛在的失效關鍵點。

LLM 在軟體重寫中的角色

pgrust 的開發引發了關於使用 LLM 進行大規模系統重寫可行性的更廣泛辯論。

「AI 重寫」範式

觀察者注意到，當 LLM 參與其中時，軟體開發方式發生了轉變：

• 可審查性： 傳統的程式碼審查變得不再切實際。一位審查者指出，在不到一個月內生成的 7,101 個 commits 是人類無法完成審查的。
• 對測試過度擬合： 存在一種風險，即 LLM 可能會對測試套件進行「過度擬合」，將測試視為字面上的規範，並透過 monkey-patching 程式碼來通過特定的數據點，而不是實作預期的通用行為。
• 維護性： 有人認為，由 AI 生成的專案更難維護，因為作者可能尚未獲得有機專案成長所具備的紀律，且未來的貢獻者可能被迫使用 AI tokens 來理解或修改程式碼。

現代化的潛力

相反地，有人認為，LLM 使將舊有基礎設施遷移到現代語言與框架變得更加容易，而這些在以前手動移植的難度過高。這種觀點認為，軟體驗證的未來將從人類程式碼審查轉向更強大的回歸測試套件與「evals」。

法律與授權考量

關於 pgrust 的授權方式目前仍有討論。雖然原始的 PostgreSQL 專案使用 PostgreSQL license，但 pgrust 是以 AGPL-3.0 授權。這引發了關於基於原始原始碼進行重寫的專案是否應受原始授權條款約束的問題。