Postgres 具備擴展性嗎？Postgres 工作流執行效能基準測試

背景

這篇文章探討了 Postgres 在處理高強度寫入負載時的擴展能力，特別是在「持久化工作流執行」的場景下。透過在 AWS RDS 上的基準測試，作者展示了單一 Postgres 伺服器每秒可處理高達 14 萬次寫入或 4 萬個工作流，並指出效能瓶頸主要在於預寫式日誌（WAL）的磁碟刷寫速度。

社群觀點

在 Hacker News 的討論中，社群對於 Postgres 的擴展性表現出高度肯定，但也針對實際應用中的複雜性提出了多維度的反思。許多開發者認為，Postgres 的垂直擴展能力已經足以應付絕大多數企業的需求，甚至能支撐每天數十億次的寫入。然而，討論也指出「擴展性」不應僅看吞吐量，高可用性與水平擴展才是實務上的難點。雖然可以透過 Patroni、etcd 或 Pigsty 等工具來達成自動故障轉移與負載平衡，但這類架構的維護成本極高。有觀點認為，過度追求分散式架構往往會引入網路延遲與最終一致性的複雜陷阱，這對開發者來說是巨大的負擔，因此在未達極限前，優先選擇垂直擴展通常是更明智的決策。

針對基準測試的結果，部分資深開發者分享了在真實大規模場景下的負面經驗。有評論提到，當資料表成長到數億行時，Postgres 的索引效能可能會出現非線性的劇烈下滑，這與 MySQL 的表現有所不同。這引發了關於資料庫調優的深入探討，社群建議透過分區表、調整填充因子（fillfactor）或使用 BRIN 索引來優化寫入密集型任務。此外，也有人提醒基準測試中使用的 UUID 類型會影響索引效率，若使用隨機 UUID 會導致索引頁面頻繁分裂，進而拖累效能。

在工具選擇上，DBOS 作為新興的持久化工作流框架受到了關注。支持者將其比作 Docker Compose，認為它比 Temporal 等老牌工具更簡潔且易於上手。儘管 Temporal 在市場上擁有較高的知名度與資金支持，但部分開發者批評其過於複雜，且有將用戶鎖定在其雲端服務的傾向。社群普遍達成共識：Postgres 的上限遠比一般人想像的高，但在追求極致效能時，必須深入理解 WAL 配置、檢查點設定以及鎖競爭等底層機制，而非盲目相信基準測試的理想數據。

延伸閱讀

• Pigsty：一套基於 Postgres 的開源資料庫解決方案，被社群認為是極佳的維運工具。
• CloudNativePG：在 Kubernetes 環境中運行與管理 Postgres 的自動化方案。
• OpenAI 案例分享：OpenAI 官方部落格曾發布關於如何擴展 Postgres 以支撐其業務需求的技術文章。
• BRIN 索引文件：Postgres 官方文件中關於區塊範圍索引的說明，適用於超大規模資料表的寫入優化。