OpenAI：一套PG搞定8億 ChatGPT 用戶

OpenAI 官方博客昨天發了一篇文章，專門講他們如何把 PostgreSQL 伸縮到今天這個量級： 一套單主 + 近 50 個只讀副本的超大 PostgreSQL 集群，支撐其核心產品（ChatGPT 與 OpenAI API）的全球訪問流量。 文章的核心內容，其實在 2025 年 PGCon.Dev 上就已對外分享過 (《》)， 但這次算是 OpenAI 官方背書，傳播面與影響力都明顯要大多了。

與半年前的分享相比，這次博客也披露了幾個關鍵變化：當時還是“一主 40 從”，如今又增加了約 10 個只讀副本；用戶規模也從 5 億增長到 8 億——增長速度確實驚人。 更重要的是：在單套集群寫入吞吐逼近天花板后，他們選擇把可分片、寫重的負載遷出 PostgreSQL，轉而落到 Azure Cosmos DB （PostgreSQL + Citus 路線）上，而不是走傳統“應用層手搓分片”的老路。

這對 PostgreSQL 的意義在于：它提供了一個極稀缺的、由時代風口公司打出來的標桿級生產案例。 過去當然也有很多公司依靠 PostgreSQL 一路扛到 IPO 或被收購（Instagram、探探等）， 但像 OpenAI 這樣對全行業產生溢出效應的案例，確實少見。所以，借著這次官方發布的窗口，我把文章內容翻譯了一遍，并按原文順序補上老馮的評論解讀。

伸縮 PG，支撐 8億ChatGPT 用戶

https://openai.com/index/scaling-postgresql/

多年來，PostgreSQL 一直是 OpenAI 核心產品（如 ChatGPT 和 OpenAI API）背后那個最關鍵、“藏在最底層” 的數據系統。 隨著用戶規模迅速增長，我們對數據庫的要求也在指數級攀升。過去一年里，我們的 PostgreSQL 負載增長了 10 倍以上，而且還在繼續快速上升。

在推進生產基礎設施以承載這股增長的過程中，我們有了一個新發現：PostgreSQL 在讀多寫少的場景下，能夠可靠伸縮到的規模，遠遠超出許多人的認知。 這個系統最初由加州大學伯克利分校的一群科學家打造，如今我們用一臺主庫（Azure PostgreSQL 靈活服務器實例?[3]）配合近 50 個分布在全球多個區域的只讀副本， 就支撐起了海量的全球訪問流量。本文會講述：OpenAI 如何通過嚴格的優化和扎實的工程手段，把 PostgreSQL 擴展到支撐 8 億用戶、每秒數百萬次查詢（QPS）；也會總結我們一路踩坑后得到的關鍵經驗。

初始設計開始出現裂縫

ChatGPT 上線后，流量以史無前例的速度增長。為了扛住它，我們迅速在應用層和 PostgreSQL 數據庫層都做了大量優化： 一方面通過增大實例規格來“縱向擴容”，另一方面不斷增加只讀副本來“橫向擴容”。這套架構很長時間里都表現不錯；而且隨著持續改進，它仍然為未來增長提供了相當充足的空間。

聽起來可能有點反直覺：單主架構竟然能滿足 OpenAI 這種量級的需求。但真要把它在現實中跑穩，并不容易。 我們經歷過多次由 Postgres 過載引發的事故（SEV，事故等級），而它們往往有著相似的套路： 上游某處出問題，導致數據庫負載突然暴漲——比如緩存層故障造成大范圍緩存未命中；某些昂貴的多表 JOIN 量激增、把 CPU 打滿；或者新功能上線帶來一波“寫入風暴”。 當資源占用不斷走高，查詢延遲開始上升，請求陸續超時；緊接著重試又會進一步放大負載，形成惡性循環，最終可能拖慢甚至拖垮整個 ChatGPT 與 API 服務。

雖然 PostgreSQL 對我們的“讀多寫少”負載擴展得很好，但在寫入流量很高的時段，我們仍然會遇到挑戰。 主要原因在于 PostgreSQL 的多版本并發控制（MVCC）實現，使它在寫密集負載下效率并不理想。 舉個例子：一次更新操作即便只改動一行里的一個字段，也會復制整行來生成一個新版本。 在高寫入壓力下，這會帶來明顯的寫放大。與此同時還會帶來讀放大：查詢為了拿到最新版本，需要掃過多份行版本（包括“死元組”）。 MVCC 還會引入一系列額外問題，比如表與索引膨脹、索引維護開銷增加、以及 autovacuum（自動清理）的調參復雜度。 （關于這些問題，可以參考我和卡內基梅隆大學 Andy Pavlo 教授共同撰寫的深度文章：The Part of PostgreSQL We Hate the Most?[4]。 這篇文章還被 PostgreSQL 的維基詞條引用過： cited?[5]。）

將 PG 擴展到百萬級 QPS

為了繞開這些限制、降低寫入壓力，我們已經把、并且仍在持續把那些可分片（可做水平切分）的寫密集工作負載遷移到分片系統中，例如 Azure Cosmos DB； 同時也在優化應用邏輯，盡量減少不必要的寫入。并且，我們不再允許在當前的 PostgreSQL 部署里新增表——新的業務默認直接落在分片系統上。

盡管我們的基礎設施一直在演進，PostgreSQL 本身仍保持不分片：所有寫入仍由單一主庫實例承擔。 主要原因是：對現有應用負載做分片會極其復雜且耗時，需要改動數百個應用端點，周期可能是數月甚至數年。 考慮到我們的負載主要是讀多寫少，再加上已經做了大量優化，現有架構仍然有充足余量來承接繼續增長的流量。 我們并不排除未來給 PostgreSQL 做分片，但在短期內這不是優先事項——因為就當前和可預見的增長而言，我們的“跑道”足夠長。

接下來的章節會展開講：我們遇到了哪些挑戰，又做了哪些大規模的優化來解決它們、避免未來故障——把 PostgreSQL 推到極限，最終把它擴展到每秒數百萬次查詢（QPS）。

降低主庫負載

挑戰：只有一個寫入節點時，單主架構無法橫向擴展寫入。寫入的突刺很容易把主庫壓垮，進而影響 ChatGPT 和 API 等服務。

解決方案：我們盡可能把主庫的壓力降到最低——包括讀和寫——確保主庫永遠留有足夠余量來應對寫入突刺。能下沉到副本的讀請求，就盡量下沉到副本。 但有些讀查詢必須留在主庫上，因為它們處在寫事務里；對這些查詢，我們重點確保它們足夠高效，避免慢查詢。 寫入方面，我們已將可分片的寫密集負載遷移到 Azure CosmosDB 等分片系統。那些更難分片、但寫入量仍然很高的負載，遷移周期更長，目前仍在進行中。 與此同時，我們也對應用做了更激進的優化來降低寫負載：例如修復導致重復寫入的應用 bug；在合適的地方引入“延遲寫”（lazy writes）以平滑流量尖刺。 另外，在對表字段做回填（backfill）時，我們會施加嚴格的速率限制，避免寫入壓力過大。

查詢優化

挑戰：我們在 PostgreSQL 中識別出多條大開銷查詢。過去這些查詢一旦出現突發的調用量飆升，就會吞掉大量 CPU，拖慢 ChatGPT 和 API 的請求。

解決方案：少數幾條昂貴查詢——尤其是涉及大量表 join 的查詢——就足以顯著降低性能，甚至把整個服務打趴下。 我們必須持續優化 PostgreSQL 查詢，確保其高效，同時規避常見的 OLTP（聯機事務處理）反模式。 比如，我們曾發現一條極其昂貴的查詢，竟然 join 了 12 張表；這條查詢的突刺曾直接觸發過多次高嚴重級別事故。 能不做復雜多表 join 就盡量不做；如果確實需要 join，我們學會了考慮拆分查詢，把復雜的 join 邏輯挪到應用層處理。 許多問題查詢來自 ORM（對象關系映射）框架自動生成，因此必須認真審查 ORM 產出的 SQL，確認行為符合預期。 另一個常見問題是 PostgreSQL 中存在長時間空閑但仍占用事務的查詢；配置類似 idle_in_transaction_session_timeout 這樣的超時參數非常關鍵，否則它們會阻塞 autovacuum。

緩解單點故障

挑戰：讀副本掛了，流量還可以切到其他副本；但只依賴單一寫入節點意味著存在單點——主庫一旦掛掉，整個服務都會受影響。

解決方案：大多數關鍵請求只涉及讀取。為降低主庫單點故障的影響，我們把這些讀取從寫入節點下沉到副本上，確保即便主庫宕機，這些請求依然能繼續對外服務。 雖然寫操作仍會失敗，但整體影響被明顯壓縮：因為讀仍然可用，這就不再是 SEV0 級別事故。

針對主庫故障，我們把主庫以高可用（HA）模式運行，并配一臺熱備：它是持續同步的副本，隨時準備接管流量。 當主庫宕機或需要下線維護時，我們可以快速提升熱備，盡量縮短停機時間。Azure PostgreSQL 團隊做了大量工作，確保即便在極高負載下，這類故障切換仍然安全、可靠。 針對讀副本故障，我們在每個區域部署多個副本并預留足夠余量，保證單個副本故障不會演變為區域級故障。

工作負載隔離

挑戰：我們經常遇到某些請求在 PostgreSQL 實例上消耗了不成比例的資源，導致同實例上的其他負載性能被拖慢。 比如新功能上線帶來低效查詢，瘋狂吃 CPU，從而讓其他關鍵功能也跟著變慢。

解決方案：為緩解“吵鬧鄰居”問題，我們把不同負載隔離到專用實例上，避免資源密集型請求的突刺影響其他流量。 具體做法是把請求拆成低優先級與高優先級兩個層級，并路由到不同實例。這樣即便低優先級負載突然變得很“吃資源”，也不會拖慢高優先級請求。我們也在不同產品與服務之間使用同樣策略，避免某個產品的活動影響另一個產品的性能與可靠性。

連接池

挑戰：每個實例都有最大連接數上限（Azure PostgreSQL 為 5,000）。連接很容易被打滿，或者積累大量空閑連接。我們曾因“連接風暴”把所有可用連接耗盡而出現事故。

解決方案：我們部署了 PgBouncer 作為代理層來做連接池。在 statement pooling 或 transaction pooling 模式下運行，它可以高效復用連接，大幅降低活躍客戶端連接數。同時也能減少建連時延：在我們的基準測試中，平均建連時間從 50 毫秒（ms）降到 5 ms?？鐓^域連接和請求成本很高，因此我們把代理、客戶端和副本盡量部署在同一區域，以降低網絡開銷并縮短連接占用時間。另外，PgBouncer 的配置必須非常謹慎，例如空閑超時這類參數對避免連接耗盡至關重要。

每個讀副本都有獨立的 Kubernetes 部署，運行多個 PgBouncer Pod。我們在同一個 Kubernetes Service 后面運行多個 Deployment，由 Service 在各個 Pod 之間做負載均衡。

緩存

挑戰：緩存未命中突然飆升，會導致 PostgreSQL 讀取請求暴漲，CPU 被打滿，用戶請求變慢。

解決方案：為降低 PostgreSQL 的讀壓力，我們使用緩存層承接絕大多數讀流量。但當緩存命中率意外下降時，大量未命中會把請求直接傾倒到 PostgreSQL 上。 數據庫讀請求的驟增會消耗大量資源，拖慢服務。為了在“緩存未命中風暴”期間防止系統過載，我們實現了緩存鎖（以及租約）機制：對同一個 key，只有一個未命中請求會去 PostgreSQL 拉取數據。 當多個請求同時未命中同一個緩存 key 時，只有一個請求拿到鎖并負責回源、回填緩存；其他請求等待緩存更新，而不是一起去打 PostgreSQL。這樣能顯著減少重復數據庫讀取，避免負載尖刺層層放大。

擴展只讀副本規模

挑戰：主庫需要把預寫日志（WAL）流式發送給每一個讀副本。副本數量越多，主庫要發 WAL 的目標就越多，網絡帶寬和 CPU 壓力都會上升，導致副本延遲更高、波動更大，使系統更難穩定擴展。

解決方案：我們在多個地理區域運營近 50 個讀副本，以盡量降低延遲。但在當前架構下，主庫必須向每個副本推送 WAL。 雖然依靠超大規格實例和高帶寬網絡，它目前還能跑得很好，但副本數量不可能無限增長——遲早會把主庫推到極限。 為此，我們正與 Azure PostgreSQL 團隊合作測試 級聯復制?（新窗口打開）[6]： 由中間副本把 WAL 轉發給下游副本。這樣可以在不壓垮主庫的前提下，把副本規模擴展到潛在的上百個。 但它也會引入更多運維復雜度，尤其是故障切換管理方面。目前該功能仍在測試階段；在投產前，我們會確保它足夠健壯，并且能安全完成 failover。

限流

挑戰：某些端點流量突刺、昂貴查詢激增或重試風暴，可能迅速耗盡 CPU、I/O、連接等關鍵資源，進而引發大范圍性能劣化。

解決方案：我們在多層做了限流——應用層、連接池層、代理層、查詢層——避免流量尖刺把數據庫實例壓垮并觸發級聯故障。同時必須避免過短的重試間隔，否則很容易形成重試風暴。 我們還增強了 ORM 層，支持限流；必要時可以直接徹底阻斷某些特定的查詢摘要（query digest）。這種“定點卸載負載”的方式能在昂貴查詢突然暴漲時快速止血、幫助系統迅速恢復。

Schema 管理

挑戰：即便是很小的 schema 變更，比如修改某列類型，也可能觸發一次 全表重寫?[7]。 因此我們對 schema 變更極其謹慎：只允許輕量操作，避免任何會重寫整表的變更。

解決方案：只允許不會觸發全表重寫的輕量變更，例如添加或刪除某些列。我們對 schema 變更強制 5 秒超時。允許并發創建/刪除索引。 schema 變更只限于已有表；如果新功能需要新增表，就必須放到 Azure CosmosDB 等替代的分片系統中，而不是繼續塞進 PostgreSQL。在做字段回填時，我們同樣施加嚴格限速，防止寫入突刺。雖然這個過程有時可能超過一周，但能換來穩定性，并避免對生產造成影響。

結果與下一步

這次實踐說明：只要設計得當、優化到位，Azure PostgreSQL 完全可以擴展到承載最大的生產級工作負載。對于讀多寫少的場景，PostgreSQL 能以百萬級 QPS 運行，為 OpenAI 最關鍵的產品（ChatGPT 和 API 平臺）提供支撐。 我們增加了近 50 個讀副本，同時把復制延遲保持在接近 0 的水平；在全球分布的區域里維持了低延遲讀?。徊㈩A留了足夠的容量余量，為未來增長做好準備。

在盡量不犧牲延遲的前提下，這套擴展也顯著提升了可靠性。我們在生產中穩定提供 p99 客戶端延遲為“兩位數毫秒級”，可用性達到“五個 9”（99.999%）。 過去 12 個月里，我們只發生過一次 SEV-0 級別的 PostgreSQL 事故（發生在 ChatGPT ImageGen 的一次 病毒式發布?[8] 期間：寫入流量突然暴漲 10 倍以上，一周內新增用戶超過 1 億。）

我們對 PostgreSQL 目前能帶來的效果很滿意，但仍會繼續把它往極限推，確保未來增長仍有充足跑道。我們已經把那些可分片的寫密集負載遷移到了 CosmosDB 等分片系統。 剩余的寫密集負載更難分片——我們也在持續推進遷移，以進一步把寫入從 PostgreSQL 主庫上卸下來。與此同時，我們還在和 Azure 一起推動級聯復制落地，確保可以安全地擴展到更多讀副本。

展望未來，隨著基礎設施需求持續增長，我們也會繼續評估更多擴展路線，包括對 PostgreSQL 做分片，或采用其他分布式系統。

老馮評論

在七年前，老馮在探探維護過一套當時可能是國內規模最大的 PostgreSQL 集群 —— 總體 250 萬數據庫 QPS，最大的核心單集群一主 32 從，大幾十萬 QPS。 我親歷過從“單集群打天下”到垂直拆分、再到水平分片與微服務改造的全過程，也完整操刀過高可用、備份恢復、監控與運維體系的設計與落地。 OpenAI 文中描述的很多問題，我們當年都踩過，所以讀起來很親切。下面按原文脈絡，聊幾個點。

單機寫入的真實天花板

互聯網業務的讀寫比通常非常極端，10:1 乃至幾十比一并不罕見。只讀查詢理論上幾乎沒有“硬天花板”：機器不夠就加副本，物理復制/級聯復制能把讀擴展得很漂亮。 真正難的是單機寫入：如果寫入速率超過單臺 PostgreSQL 的承載能力，就不得不走向分庫分片。

在現代硬件上，單機 PostgreSQL 的寫入瓶頸往往體現為 WAL 速率、寫事務吞吐、以及背后存儲的持續寫能力上限。 你可以通過更強的 CPU、更快的 NVMe、更大的內存把這條線往上推很遠，但它終究存在，而且一旦撞上就只能做結構性拆分。

作為經驗參考，單機 PostgreSQL 的寫入瓶頸通常在 100-200 MB/s 的 WAL 速率，或者 100-200 萬/s 的點寫入事務。 這是什么概念呢？當時探探作為一個千萬日活的 IM 應用，所有數據庫全局的 WAL 寫入速率加起來，大概在 110 MB/s。 當下的頂級硬件可要比八年前牛逼太多了，讓 OpenAI 這樣的創業公司可以用一套 PostgreSQL 集群，在不分片，不Sharding 的情況下直接服務整個業務。

OpenAI 這篇文章的價值之一，是用一個極強的現實樣本把問題講清楚：對接近十億用戶量的應用， 核心業務仍然可以在相當長時間里維持“單主 + 大規模只讀副本”而不立刻分片。 很多“”敘事，至少在 OpenAI 這個例子面前變得滑稽起來。

MVCC 膨脹的利弊權衡

文中提到的文章 —— 《PostgreSQL 中我們最討厭的部分》是這篇博客的作者 Bohan 操刀，Andy 潤色掛名的。 我在跟 Bohan 聊天時我問他怎么起這么個爭議性的名字，他坦誠說這是為了上 HN 選的標題，哈哈。 討論的是 PostgreSQL MVCC 的代價：寫放大、膨脹、vacuum、freeze 等。這些問題客觀存在，也是很多數據庫“攻擊 PG”的常用火力點。

但老馮覺得工程的核心在于 “利弊權衡” —— PG 的 MVCC 實現固然會有寫放大，表膨脹，需要垃圾清理等問題。但這種 MVCC 設計帶來的好處也是實實在在的 —— 極低的復制延遲與穩定的流復制提高了可靠性，讀與寫互不鎖定極大提高了并發吞吐，不限量且能瞬間回滾的巨型事務讓OLAP變得可能， 可以后臺擇機垃圾回收平滑 IO 使用；定期 vaccum / repack / freeze 處理表膨脹確實引入了額外的維護任務， 它們本質是 可工程化治理的問題，你愿意為這些好處支付怎樣的運維成本，這才是該問的問題。

該分片還是得分片

OpenAI 在文章中提到，盡管寫入已經接近瓶頸了，但他們還是保持 PostgreSQL 本身不分片。不過他們凍結了這套 PostgreSQL 集群的新業務， 而是轉移到了 Azure Cosmos DB 上去。CosmosDB for PostgreSQL 據我所知實際上是 PostgreSQL + Citus —— PG + 分布式擴展，所以實質上還是在增量部分做了分片。

探探最開始也是一套數據庫集群打天下，然后垂直拆分成了 20 套獨立的集群。但是有幾個核心業務還是撐不住，所以就參照 Instagram 的 PostgreSQL 水平分片架構， 搭建了一套 Shard 集群，擴展到 64 個shard，128 臺物理機的手，甚至還對這些 Shard 又進行了垂直拆分，幾個核心場景 —— 聊天，朋友圈，關注關系最后都有了自己的水平分片。

當時我們也有一套 Citus 集群，不過那個時候的 Citus 還沒被微軟收購，有些重要的運維功能（分片再平衡）沒有開源。再加上運維管理，一致性備份恢復， 高可用都相當麻煩，最后還是下掉了。不過今天這些問題都解決了，所以如果是今天老馮要分片 PostgreSQL，我的首選也會是 Citus。

主庫優化：數據重力確實考驗 DBA 能力

因為 OpenAI 選擇了對現有 PostgreSQL 集群不分片，這就意味著你必須把單主榨到極限，這里面會出現大量非常細的工程技巧： 寫入治理、慢查詢狙擊、連接風暴防控、緩存雪崩應對、DDL 變更紀律、限流熔斷、快慢分離等等 —— 每一項說開了都不神秘，但這也是真正體現 DBA 功力的地方。

當年我們也遇到過一個困境 —— 應用設計之初，走的是北歐 Old School 風格 —— 幾乎所有業務邏輯都是用存儲過程實現的。 不只是 CRUD，而是一些相當復雜的邏輯，比如 100ms 的 SQL 推薦算法， WGS8S轉火星坐標系這種 GIS 處理。所謂后端就是很薄的一層轉發，把 URL 映射到存儲過程執行。

這里體現的是一項利弊權衡，當數據庫性能有余量的時候，你可以通過把邏輯作為存儲過程放入數據庫來利用這些閑置的性能，以及其他一些精妙的好處。 直到幾百萬日活的時候，這套架構運行的都非常不錯，然而當主庫撞上瓶頸之后，我們就不得不把這些東西從數據庫中搬出來，在業務代碼中實現。

此外，一套極高負載的主庫，在管理上需要許多精細化的操作。一些小庫上大大咧咧的 ALTER TABLE 和 UPDATE 整表，在生產集群上也要慎之又慎，非?？简?DBA 的功力。 不過最近這幾年，PostgreSQL 在這方面的改進了許多，許多 DDL 操作現在都可以快速在線完成，不需要表重寫或者獲取強鎖了。 也有像 Bytebase / pgschema 這樣的工具，可以處理好許多變更的細節。總的來說，管理這件事是比幾年前容易多了。

關于 ORM

看來 OpenAI 已經在 ORM 上踩過坑了 —— 老馮對于 ORM 這樣的中間層是非常不感冒的，因為它經常會生成非常糟糕的套娃 SQL，我覺得這對于專業程序員來說是一個典型的負優化。

那么有沒有辦法在保留 ORM 便利性的同時，生成可靠，穩定的 SQL 呢？那時候我們用的是一個叫 sqlc 的工具，它能自動根據數據庫模式生成 Go 語言結構體以及各種增刪改查方法。 這樣既不用手寫狗屎代碼，又確保了 SQL 是靜態，穩定，高度可預測的。特別是在當下 AI Coding 已經有很強能力的情況下，我更看不出使用 ORM 的必要了。

關于高可用與級連從庫

文中看起來是“主庫直掛近 50 個副本”。這既說明了 PostgreSQL 足夠皮實，也意味著主庫要承擔非常可觀的 walsender、網絡與 CPU 壓力。 我們當年在硬件與網絡更弱的時代，主庫直掛超過 10 個副本就已經能觀察到明顯影響，所以會強制采用級聯復制：主庫只直掛一部分副本，更多副本掛在“橋接副本”上轉發 WAL。

在七年前的硬件條件與網絡條件下，老馮觀察到一臺 PG 主庫拖 10 臺從庫，就已經會產生顯著影響了 —— 比如網絡帶寬與 CPU。所以我定了一條規則，一個主庫最多直接掛 10 個從庫，超過 10 個之后，就要開始級聯復制。

比如，當時我們 1主32 從的拓撲是這樣的，主庫上直接掛了 10 臺從庫，另外 20 臺，分別掛在兩臺 “橋接從庫” 上，每臺下面再掛 10 臺。橋接從庫是不承載只讀請求的，只干一件事，就是轉發。 如果出現主庫故障，我們的 SOP 就是提升一臺橋接從庫，然后把其他的從庫重新掛上來。這種做法可以確保切換之后，新集群立刻有 10 個能直接用的從庫。

OpenAI 也在測試級聯復制，這是正確方向。但級聯復制真正難的不是“能不能轉發”，而是故障切換后的拓撲重建與自動化 SOP。 這部分如果做不好，級聯會把運維復雜度放大，而不是降低風險。

當然，現在高可用這件事，已經比以前簡單太多了。老馮昨天的文章《PostgreSQL 高可用到底如何做？》就介紹了 PG SOTA 高可用方案 Patroni 的實操

關于工作負載隔離

當你的集群上量之后，一個重要的工作是 “快慢分離” ，OpenAI 顯然已經遇到了這樣的 “吵鬧鄰居” 問題。 當 “快查詢” 和 “慢查詢”， 或者說 “在線查詢” 與 “離線查詢” 混合在一起的時候，就會出現各種奇妙的反應。

所以當時我們在設計集群架構的時候，除了 primary 主庫，replica 從庫 這兩種經典角色之外，還有一個 offline 離線實例的角色 （實際上還有 bridge 橋接從庫，standby 同步從庫，delayed 延遲從庫 三種）。Offline 實例的作用就是把那些 SAGE 長事務，ETL 工作流，以及個人用戶/數據分析師查數據這些 “非在線” / “準在線” 業務移動到專用實例上去，避免影響在線業務。

快慢分離的另一端是 “快查詢”。對于互聯網場景來說，絕大多數點查詢都可以受益于緩存。也就是弄個 Redis。 盡管如此，可能在打到 250 萬 QPS 和 大幾百萬日活之前，我們都 沒有用緩存，直接用 PG 硬扛 —— 事實上它也扛下來了。 對于開發者來說，這里有一個啟發是 —— 其實真沒有必要那么早就弄緩存把事情搞復雜。

后來我們還是全面鋪開了 Redis，Redis 大概有 13000 核 vCPU 的規模，PG 則只剩下了 12000 vCPU 。 Redis 的全局 QPS 達到了四百萬，而 PG 則只剩下了 50 萬左右的 QPS，從效果上來看還是可以的。CPU 利用率都掉到個位數了，搞得后來又要搞合并精簡。

關于連接池

連接池依然是提升高并發/高負載下 PostgreSQL 性能的靈丹妙藥，而當下的 PG 連接池最優選依然是 pgbouncer —— 它提供了事務池化的能力，極致的性能，額外的監控指標采集點（查詢 RT），靈活的管理能力，流量路由抓手。

pgbouncer 的事務連接池有化腐朽為神奇的效果。舉個例子，大幾千條客戶端連接，幾萬的 QPS，通過 pgbouncer 池化排隊之后， 可以收斂到 3 到 4 條數據庫連接！這意味著原本幾千個數據庫進程變成幾個進程，幾千個事務相互踩踏變成幾個并發事務相安無事。

唯一美中不足的是，它是一個單進程的應用。因此大概在 5萬 QPS / 大幾千條連接到時候打滿自己的單核 CPU。 好在你可以部署多個 pgbouncer 實例一起使用。OpenAI 這里選擇了把 pgbouncer 連接池放在了應用一側，這個方式挺好，但是需要研發配合。 老馮當時是在數據庫一側，放在 HAPROXY 后面，掛了多個 pgbouncer 連接池。

但多個連接池管理，監控起來還是有些麻煩的。最近也有好幾個新的 PG 連接池項目，老馮比較關注看好的是 pgdog ，希望可以解決好這個問題。

總結

我的朋友 瑞典馬工 在 《》 里面提出了一個觀點， 決定數據庫勝負的三要素是：技術套件，標案案例，生態系統。

在生態系統上，PostgreSQL 已經毫無疑問主宰了數據庫世界，而 OpenAI 則提供了一個 標桿案例。 而老馮這幾年做的事情，就是把生產級 PostgreSQL 的技術套件做成可復制、可交付、可普及的 技術套件：把“能跑到 OpenAI 這個量級之前都用得上”的能力，盡量下放給更多團隊。

探探那套 PostgreSQL 的實戰經驗，我沉淀成了 Pigsty：企業生產級的開源 PostgreSQL 方案，覆蓋高可用、時間點恢復、SOTA 監控、IaC/CLI 批量管理，以及上百/數百擴展的交付能力。 OpenAI 的例子再一次證明，絕大多數企業根本不需要花里胡哨的數據庫大觀園，扎扎實實的用好一套 PostgreSQL，就足夠支撐你的業務一路干到 IPO 了。

References

[1]: https://www.pgevents.ca/events/pgconfdev2025/schedule/session/433-scaling-postgres-to-the-next-level-at-openai/"
[2]:https://openai.com/index/scaling-postgresql/
[3]Azure PostgreSQL 靈活服務器實例?:https://learn.microsoft.com/en-us/azure/postgresql/overview
[4]The Part of PostgreSQL We Hate the Most?:https://www.cs.cmu.edu/~pavlo/blog/2023/04/the-part-of-postgresql-we-hate-the-most.html
[5]cited?:https://en.wikipedia.org/wiki/PostgreSQL_note-37
[6]級聯復制?（新窗口打開）:https://www.postgresql.org/docs/current/warm-standby.html-REPLICATION
[7]全表重寫?:https://www.crunchydata.com/blog/when-does-alter-table-require-a-rewrite
[8]病毒式發布?: https://newsletter.pragmaticengineer.com/p/chatgpt-images