Connection pool giữ sẵn các kết nối và tái dùng thay vì mở/đóng liên tục. Đo thật trong Go 1.23: một pool dựng bằng buffered channel tái dùng 3 kết nối cho 10 lần dùng, có timeout khi cạn, và nhanh hơn tạo mới mỗi lần hàng nghìn lần khi kết nối tốn 5ms bắt tay.
sql.DB không phải một kết nối — nó là một pool. Hiểu sai ba nút MaxOpenConns, MaxIdleConns, ConnMaxLifetime khiến app hoặc nghẽn cổ chai hoặc giết chết DB. Đo thật trong Go: cùng 1000 truy vấn, throughput đi từ 174 lên 8497 truy vấn mỗi giây khi chỉnh pool, và WaitCount về 0 khi đủ kết nối.
Mỗi kết nối PostgreSQL là một process riêng tốn RAM, và max_connections có trần cứng — ngàn client làm cạn kết nối, database từ chối. PgBouncer đứng giữa, gộp nhiều client vào một pool nhỏ. Bài này dựng THẬT Postgres + PgBouncer: 30 client chỉ thành 5 backend, và đo chi phí thiết lập kết nối đắt gấp 50 lần giữ kết nối.
Keep-alive tái dùng một kết nối cho các request tuần tự, nhưng khi nhiều request chạy song song, mỗi luồng cần một kết nối cùng lúc — đó là việc của connection pool. Bài này chạy thật trong Go: 2000 request song song 50 luồng với pool mặc định (2) mở tới 546 kết nối vì churn, còn pool đủ lớn chỉ mở 50 và nhanh hơn. Giải thích cách chọn kích cỡ pool đúng.
PgBouncer 1.26 ở transaction mode với pool 20 trước PostgreSQL 16 max_connections 100. Connect mỗi giao dịch: 1.224 TPS trực tiếp, 2.322 qua pool. 300 client trực tiếp nhận FATAL too many clients; 1.000 client qua pool chạy trên 20 backend với 951 client xếp hàng, 64.088 TPS. Nhưng PgBouncer một luồng chạm trần 70.000 TPS truy vấn đơn giản so với 235.000 trực tiếp. Một client SET work_mem rồi ngắt: 50 trong 50 client mới nhận 64MB vì transaction mode không reset phiên. Prepared statement lỗi với max_prepared_statements 0, chạy 89.480 TPS khi bật 100. Pool cạn: SELECT 1 chờ 2,9 giây.