今天要來聊一個超有料的主題——ChatGPT 背後的資料庫架構，以及微軟工程團隊如何幫 OpenAI 撐過爆炸性的用戶成長。 這篇文章源自微軟官方部落格，由 Azure PostgreSQL 工程副總裁 Affan Dar 領銜撰寫。乾貨滿滿，讓我來幫你翻譯成人話。
先說背景：ChatGPT 有多誇張？
OpenAI 過去一年把資料庫規模擴大了 10 倍，要支撐的是高達 8 億月活躍用戶。這個量級是什麼概念？整個系統底層用的是 Azure Database for PostgreSQL，也就是微軟雲端上的 PostgreSQL 託管服務。 PostgreSQL 這個開源資料庫，平常我們可能覺得它就是個「普通關聯式資料庫」，但這次的故事告訴我們：只要配置得當，它真的可以撐到超大規模。
問題一：讀取副本老是跟不上主節點
什麼是讀取副本（Read Replica）？
簡單說，就是把資料庫「複製一份」給其他伺服器來分擔讀取流量，這樣主節點就不用一個人扛所有查詢。ChatGPT 的架構裡，一台主節點撐著超過 50 個分布在多個地區的副本，這數字已經很嚇人了。
發生了什麼問題？
在 OpenAI 某次大型服務上線前，工程師發現一個詭異現象：副本的資料會「越落越遠」，跟不上主節點的更新速度（這叫做 Replication Lag，複製延遲），而且它不會自己恢復，只能靠重啟副本才能解決，然後一天內又再次發生——陷入一個惡性循環。
問題的根源是什麼？
深挖之後，找到了罪魁禍首：TCP 壅塞控制演算法。 預設的 CUBIC 演算法在偵測到封包遺失（跨地區傳輸本來就難免）時，會把傳輸速度猛踩煞車，拼命退讓，導致複製速度大幅下降。
怎麼解決？
微軟團隊做了三件事：
- 把壅塞控制演算法從 CUBIC 換成 BBR（對封包遺失更不敏感）
- 調整 TCP 視窗大小設定
- 引入**公平佇列（Fair Queuing）**網路排程，讓封包傳送更平滑 這三招組合拳下去，問題就解決了。
問題二：讀副本超過 50 個後怎麼辦？
微軟加入了**串聯副本（Cascading Replica）**支援，讓副本可以再複製給下一層副本，不用所有副本都直接連主節點。這樣就能在不影響主節點的情況下，繼續橫向擴展讀取能力。 此外，他們還開發了一個新技巧：從同地區的另一個副本快照建立新的異地副本，避免過去需要跨地區大量複製資料（可能要花幾小時甚至幾天）的痛苦。
問題三：寫入量太大，單台主節點 IOPS 不夠了
讀取問題解決了，但寫入量的成長讓單台 PostgreSQL 主節點的 I/O 效能上限捉襟見肘。這也是為什麼 OpenAI 後來把部分適合拆分的新工作負載移到 Azure Cosmos DB（NoSQL）去了。 但問題是，有些資料就是很難拆分（sharding 困難），這時候怎麼辦？ 這就帶出了微軟的新架構：Azure HorizonDB，在 2025 年 11 月進入私人預覽。
Azure HorizonDB：為超大規模打造的 Postgres
這是目前最令人興奮的部分。HorizonDB 從根本上重新設計了 PostgreSQL 的儲存層，核心概念叫做「以 WAL 為中心的儲存模型」。
WAL 是什麼？
WAL（Write-Ahead Log，預寫日誌）是資料庫記錄「我要做什麼改變」的日誌，用來確保資料不會因為系統崩潰而遺失。PostgreSQL 傳統上是先寫 WAL、再把資料頁寫到磁碟。
HorizonDB 的創新在哪？
PostgreSQL 的計算節點不再直接寫資料頁到磁碟，所有持久化都透過 WAL 完成，資料頁由獨立的儲存層負責重建。 儲存層分成兩個獨立服務：
| 服務 | 優化目標 |
|---|---|
| WAL Server | 超低延遲的順序寫入 |
| Page Server | 超大規模的隨機讀寫 |
| WAL Server 可以在一次網路跳轉內就把一筆交易持久化到 3 個可用區域（傳統架構需要 4 次跳轉），大幅降低提交延遲。 | |
| Page Server 則把資料分散在大量 NVMe 高速磁碟上，讓單個 PostgreSQL 實例可以達到數十萬 IOPS 的讀取能力。 |
計算節點變成無狀態引擎
最妙的是，這個架構讓 PostgreSQL 的計算節點從此「輕裝上陣」——備份、複製、Checkpoint 等繁重工作全部交給儲存層，計算節點只需要專心處理業務邏輯，CPU、磁碟、網路資源都省下來了。 讀取副本也不再需要各自保存一份完整的資料拷貝，瞬間就能建立新副本，且每多一個副本完全不影響主節點效能。
總結：從這件事可以學到什麼？
這篇文章最有價值的地方，不只是技術細節，而是工程師解決問題的思路： 先找根本原因，而不是用重啟來掩蓋問題（TCP 壅塞控制的案例）。一步一步拆解問題，先解讀取延遲、再解讀取擴展、最後解寫入擴展。為未來設計，HorizonDB 的架構不是為了應付今天的問題，而是為了更大的明天。 PostgreSQL 在 8 億用戶的規模下能正常運行，背後是無數工程師的調校與創新。下次有人說「PostgreSQL 不能水平擴展」，你可以把這篇故事講給他聽。
原文來源：Microsoft Community Hub — Supporting ChatGPT on PostgreSQL in Azure（2026/1/29）