PostgreSQL fork một tiến trình riêng cho mỗi kết nối, nên nhiều kết nối tốn RAM và CPU. Đo thật: 60 kết nối tạo 60 tiến trình, ps RSS gợi ý 16 MB/kết nối nhưng đó là con số ảo do đếm trùng shared_buffers — RAM thật của kết nối idle chỉ ~0,44 MB. Vì sao vấn đề thật nằm ở kết nối hoạt động và context switch. PostgreSQL 16.
Một kết nối PostgreSQL có hai loại chi phí: thiết lập (fork backend, xác thực, nạp catalog) và bộ nhớ tích lũy. Đo thật: mở lại kết nối mỗi truy vấn cho 1.306 TPS so với 24.228 TPS khi tái dùng — chậm 18 lần. Và bộ nhớ backend phình từ 1,3 MB lên 2,1 MB khi chạm nhiều bảng. Vì sao pooling là giải pháp kỹ thuật. PostgreSQL 16.
Đặt max_connections cao không cho throughput cao hơn — số truy vấn chạy song song bị chặn bởi số core CPU. Đo thật trên máy 10 core: TPS đạt đỉnh ở ~16 client rồi TỤT 20% khi lên 90 client vì context switch. Vì sao max_connections là trần an toàn chứ không phải mục tiêu, và công thức thực tế. PostgreSQL 16.
PgBouncer là lớp pooler nhẹ gom hàng trăm client vào vài chục kết nối thật tới PostgreSQL. Đo thật với PgBouncer 1.25: mở lại kết nối qua pooler cho 15.824 TPS so với 3.368 TPS trực tiếp — nhanh 4,7 lần; và 100 client chỉ tạo 20 backend thật đúng bằng pool_size. Ba chế độ pooling và khi nào dùng chế độ nào. PostgreSQL 16.