Cursor 推出 Continuity：利用 S3 預寫日誌實現可擴展 Git 儲存，支援大型儲存庫與閒置 AI 代理倉庫

Cursor 推出 Continuity：以 S3 預寫日誌打造可擴展 Git 儲存

Cursor Origin 最近公開其底層 Git 儲存系統 Continuity，採用 S3 相容物件儲存的 預寫日誌（WAL） 作為唯一的資料來源。開發者推送程式碼時，系統先完整寫入 S3，隨即回覆成功；本機則保留標準 Git 儲存庫與高速 NVMe 快取，作為日常讀寫的暫存層。即使伺服器上的副本遺失，也能從 S3 立即重建，免除固定追蹤每個儲存庫所在機器的負擔。

為何需要兩種不同的擴充策略？

1. 大型單一儲存庫

   企業的核心代碼庫往往持續成長，讀取流量隨之激增。傳統做法是將同一儲存庫複製到多台伺服器以分擔讀取，但每增加一份副本，推送時就必須同步到更多節點，寫入延遲會上升。Continuity 讓副本數可彈性調整，讀取端可隨需求增減，寫入仍只受 S3 的吞吐量限制。

2. AI 代理產生的小型儲存庫

   隨著生成式 AI 的普及，許多 AI 代理會自動建立 Git 儲存庫以保存模型或腳本，但這類儲存庫大多閒置。傳統固定保留多份副本會浪費計算與儲存資源。Continuity 能在閒置一段時間後將磁碟上的副本移除，需用時再從 S3 重新恢復，實現「按需」儲存。

效能測試與業界背景

Cursor 進行的合成壓力測試顯示，當副本數擴展至 100 個 時，唯讀 Git 操作仍隨副本數線性提升，未觀測到推送速度下降。使用 S3 Standard 時，系統每秒可處理 120 次 推送；改用延遲較低的 S3 Express One Zone，吞吐量突破 300 次/秒。

此舉正逢 GitHub 面臨儲存容量急速成長的挑戰。8 月 17 日，美國中部資料中心因關鍵元件無法即時擴充，服務中斷近 7 小時 47 分鐘。GitHub 官方指出，自 4 月以來，每月提交次數已從 14 億 增至 29 億。目前 Azure 承擔 GitHub 約 58% 的平台負載與一半的 Git 操作，未來將先從大型單一儲存庫導入可隨讀取端數量增減的新架構。

未來展望

Continuity 的設計示範了「資料永遠在雲端、快取只在本機」的思路，為大型企業與大量 AI 代理提供了兼顧效能與成本的解決方案。若其他 Git 託管平台也能效仿此模式，未來的程式碼託管服務將更能彈性應對持續增長的提交量與多樣化的使用情境，開發者不必再為副本管理與資源浪費而煩惱。