RDS PostgreSQL Connection Pool (Transaction Mode)¶
概念概覽
連線數瓶頸量化¶
核心知識¶
連線數瓶頸量化¶
- RDS db.r6g.2xlarge（32GB RAM）
max_connections ≈ 3,604 - 500 Pod × 預設連線池 = 41,472 條，超出上限 11.5 倍
- 壓測佐證：200 CCU 時 144 個 DB 連線中最多只有 4 個 active，idle 率 97% → 這是 Transaction Mode 可行的關鍵前提
Transaction Mode 限制（部署前必查）¶
- 不支援 prepared statements（需 App 端調整）
- 不支援 LISTEN/NOTIFY
- 只在 App 真正執行 SQL 時借用真實連線，讓 41k App 連線共用約 2,000–3,000 條真實連線
RDS Proxy vs PgBouncer 選擇依據¶
| RDS Proxy | PgBouncer | |
|---|---|---|
| 管理成本 | AWS 托管，自動 scale | 需自行維護 HA |
| 費用 | ~$0.015/hr per vCPU | 開源免費 |
| 連線上限 | 自動 scale | 單進程建議上限 10,000–50,000 |
連線數需求 < 50k 且不想管理 HA，優先 RDS Proxy；需要精細控制且已有 K8s 運維能力，選 PgBouncer。
經驗教訓¶
-
idle 率是判斷 Transaction Mode 是否值得引入的核心指標，壓測時必須量測
-
RDS Proxy 費用以 vCPU 計算，升規格會連帶增加 Proxy 費用，需一併考量
-
PgBouncer 單進程瓶頸在 10k–50k 連線，超出需多進程或改用 RDS Proxy
常見陷阱¶
-
Transaction Mode 與 prepared statements 不相容，部署前未確認 App 端用法會導致功能異常
-
升級 RDS 規格（如 db.r6g.4xlarge）max_connections 只到 ~7,200，仍遠不足 41,472，規格升級無法替代連線池
最佳實踐¶
-
先從壓測數據取得 active/idle 比率，再決定是否引入 Transaction Mode
-
部署 Pooler 後必須壓測 Pooler 本身的延遲影響，而非只看 RDS 端指標
-
PgBouncer 部署於 EKS 時需配置 PodDisruptionBudget 確保 HA
相關概念¶
- CCU Capacity Planning（壓測數據推算法）
- EKS Node Group Migration Runbook
- PostgreSQL Checkpoint IO Storm
- rds-proxy----dangling---
來源 Sessions¶
| 日期 | Session | 貢獻摘要 |
|---|---|---|
| 2026-03-25 | 135234ac-cc13-4bd9-92f0-c123f2169ae2 | 建立從壓測數據（idle 率 97%）推導 Transaction Mode 可行性的量化方法，並完整比較 RDS Proxy 與 PgBouncer 的適用邊界 |