# Cursor 將 Git 儲存系統 Cursor Origin 按資料庫設計以支援大規模工作負載

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 原作者：Cursor (@cursor_ai) · 策展與摘要：EasyVibeCoding · 平台：X (Twitter) · 熱度：🔥🔥🔥🔥 · 日期：2026-08-19

> 原始來源：https://x.com/cursor_ai/status/2089758713183613266

## 證據與延伸閱讀

- [Cursor 將 Git 儲存系統 Cursor Origin 按資料庫設計以支援大規模工作負載。](https://cursor.com/blog/git-at-any-scale) — 官方文件
- [Cursor 於 2026 年 8 月 19 日分享文章](https://x.com/cursor_ai/status/2089758713183613266)

## 中文摘要

Cursor 將 Git 儲存系統 Cursor Origin 按資料庫設計以支援大規模工作負載。

**分享重點** Cursor 於 2026 年 8 月 19 日分享 Vicent Martí 前一天發布的文章〈Git at any scale〉，藉此交代 Origin 的設計脈絡。文章指出，Git 的分散式特性在伺服器端反而帶來挑戰：packfile 以壓縮與 delta 方式儲存物件，讀取時必須同時穿越 DAG 與磁碟資料配置，難以直接依靠網路檔案系統擴充。

**既有架構限制** GitHub 早期曾嘗試 NFS、GFS 與 DRBD，後來改以遠端 RPC 存取專用檔案伺服器；約 2013 年形成的 Spokes 則在本機 NVMe 磁碟保存完整 Git repository，並以多副本與 3PC 維持一致性。這套方法能讓 fetch 與 clone 快速，也避免 eventual consistency 造成推送後讀不到 commit 的問題。

**面向新工作負載** 文章認為，Spokes 的 3PC 使每個步驟都受最慢節點限制：副本越多，push throughput 越差。2026 年企業 monorepo 需要更多副本承擔 CI 流量；另一方面，Agent 大量建立短命小型 repository，也讓每個 repository 固定維持三份副本變得浪費。Cursor 因此回顧這些取捨，並將 Origin 視為資料庫來設計與操作，以回應可靠性、效能與規模化需求。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/6ee8c06d260ee2d4.gif)
> 淺綠色背景的網格幾何圖形，畫面左下角為起點，向右上延伸出數條對角虛線，並有多條縱橫實線交錯劃分出大小遞增的矩形區塊。

## 標籤

Cursor, IDE, Cursor, GitHub