在現今應用架構中， Auto Scaling 早已成為服務穩定與資源彈性調度的核心機制。不論是負載突增時自動增加機器，或是在流量下降時減少機器， Auto Scaling 都能有效節省成本並確保 SLA 。然而，當我們將注意力放在機器的數量時，卻常常忽略了一個重要的 bottleneck - 資料庫的最大連線數（ max_connections ）。

在明天的文章，將分享如何透過 JMeter 對調整過 max_connections 的 PostgreSQL 進行壓力測試，並探討在 Auto Scaling 架構下，資料庫最大連線數是否會成為效能瓶頸（ bottleneck ），進而影響整體服務的可擴展性。今天，就先讓我們來聊聊什麼是 max_connections 。

max_connections 是一個資料庫參數，不只在 PostgreSQL 中，在 MySQL 也有這個參數，用來設定「同一時間最多有多少個 client 可以同時連線到這個資料庫」。每當有一個 client（不論是應用程式、分析工具或管理介面）嘗試建立一條連線時，PostgreSQL 都會為這個連線新增一個 process 。

PostgreSQL implements a "process per user" client/server model. In this model, every client process connects to exactly one backend process. As we do not know ahead of time how many connections will be made, we have to use a "supervisor process" that spawns a new backend process every time a connection is requested.

max_connections 的預設值是 100，但這個數字可以根據系統需求與硬體資源進行調整，而因為增加一個連線需要產生一個 proccess，資料庫需要分配額外的記憶體和資源，因此這個參數不建議無限制地提高。如果 client 連線數超過這個上限，多出來的連線請求就會被拒絕，導致應用層出現錯誤或延遲。