把Git塞進數據庫的人想干什么

「Import any git repo, query its entire history with SQL」——當開發者第一次看到這句話，反應通常是：這有必要嗎？

但Neon的工程師用20個真實倉庫、27萬次提交的數據證明了一件事：把版本控制從文件系統搬進PostgreSQL，不只是為了炫技。壓縮率能跑贏git gc --aggressive，查詢能力卻是降維打擊。

正方：數據庫原生就是版本控制的終極形態

pgit的核心假設很直接：Git的存儲模型是1980年代的設計——文件系統、對象數據庫、壓縮包。而現代開發者的真實痛點是歷史數據的分析。

傳統方案是什么？寫腳本解析git log，用awk和grep拼湊答案，或者把數據導出到第三方工具。pgit的作者在HN原帖里列了一個典型場景：

「pgit analyze coupling」——一條命令輸出文件共現矩陣。src/parser.rs和src/lexer.rs在127次提交中被同時修改，src/db/schema.go和migrations.go綁定了84次。

這背后是原生SQL的查詢能力。文件版本存在pgit_file_refs表，路徑映射在pgit_paths表，commit_id作為關聯鍵。想算耦合度？JOIN、GROUP BY、ORDER BY，數據庫最擅長的操作。

更關鍵的是存儲層。pgit用了pg-xpatch，一個PostgreSQL表訪問方法（Table Access Method），自動對連續版本做增量壓縮。SELECT時透明還原，INSERT時只存delta。

20個倉庫的benchmark結果：12個倉庫的壓縮率優于git gc --aggressive。不是全部勝出，但考慮Git用了三十年優化的壓縮算法，一個新工具能在60%場景跑贏，已經說明問題。

作者還扔了一個更具象的例子：給AI agent一個prompt，10分鐘內生成Neon自有倉庫的完整健康報告。這個場景里，SQL接口的價值遠大于壓縮率——結構化數據才是LLM的舒適區。

反方：這是開發者真正需要的嗎？

質疑的聲音同樣直接。Git的勝利不是技術選型最優，而是生態鎖定和工作流慣性。

pgit的CLI設計刻意模仿Git（init, add, commit, push, pull, diff, blame），這本身就是妥協。開發者學的是命令，不是SQL。當pgit說「drop down to raw SQL」時，已經過濾掉了大部分用戶。

再看內置分析命令：churn（變更熱點）、coupling（文件耦合）、hotspots（維護熱點）、authors（貢獻者）、activity（活躍度）、bus-factor（關鍵人風險）。這些確實是代碼健康度的核心指標，但Git生態里早有成熟方案。

git-churn、code-maat、hercules、git-of-theseus……工具鏈已經存在。pgit的差異化是「一條命令出結果」，但代價是整個倉庫必須導入PostgreSQL。對于大型倉庫，這是時間和空間的雙重成本。

壓縮率的benchmark也有解讀空間。git gc --aggressive是保守策略，不是Git的極限。Git的delta壓縮基于啟發式排序（優先找相似文件），而pgit的pg-xpatch是順序版本差分。兩種模型各有最優場景，20個倉庫的樣本未必普適。

最尖銳的問題：SQL查詢能力真的是剛需嗎？作者展示的那個耦合度查詢，用git log --name-only配合Python腳本，50行代碼也能實現。pgit的優勢是「不用寫腳本」，但前提是團隊已經運維PostgreSQL。

判斷：工具鏈分層的新信號

pgit的真正價值不在替代Git，而在暴露一個被忽視的需求：版本歷史的數據化。

Git的設計哲學是「內容尋址的不可變對象存儲」，這保證了分布式協作的可靠性，但也把歷史數據封死在自定義格式里。想要分析？先解析、再轉換、再計算。

pgit的激進之處在于反向操作：先用數據庫的存儲模型重新實現版本控制，再把Git作為導入來源之一。這不是fork Git，而是demote Git——從核心基礎設施降級為數據源之一。

這個模式能跑通的前提，是PostgreSQL的生態系統足夠成熟。pg-xpatch作為表訪問方法，意味著壓縮邏輯對上層透明，普通SQL查詢無需感知delta存儲的存在。這是數據庫內核層面的擴展能力，不是應用層能復制的。

對于目標用戶——25-40歲的科技從業者——pgit的啟示更具體：當AI開始參與代碼審查和架構決策，結構化數據接口的價值在指數級上升。給LLM喂git log文本，和喂SQL查詢結果，效率差距不是線性而是數量級。

作者那個「10分鐘生成健康報告」的demo，指向一個更務實的使用場景：pgit不適合日常開發工作流，但適合周期性的架構健康度審計。導入一次，分析一波，導出結論，拋棄或歸檔。

工具鏈正在分層。Git守住協作的基本盤，pgit這類工具搶占分析的高地。兩者不是取代關系，而是專業化分工。對于需要量化技術債務、評估重構優先級、追蹤關鍵人風險的團隊，SQL接口的靈活性確實無可替代。

下一步值得觀察的：pgit是否開源，pg-xpatch能否獨立復用，以及最重要的——有沒有真實團隊愿意在生產環境跑通這個架構。技術驗證已經完成，商業驗證才剛開始。