ทำไมคุณจึงต้องการ connection pooling (PgBouncer)?

Question

Accepted Answer

**Connection pooling** นำชุด connection ฐานข้อมูลขนาดเล็กกลับมาใช้ใหม่ข้าม client request จำนวนมาก แทนที่จะเปิด connection ใหม่ต่อ request connection ของ PostgreSQL **มีต้นทุนสูง** (แต่ละตัวเป็น process แยกที่ใช้หน่วยความจำมาก) ดังนั้น pooling จึงจำเป็นต่อประสิทธิภาพและความสามารถในการขยายภายใต้ load **PgBouncer** เป็น pooler มาตรฐาน

## ปัญหา: connection ของ PostgreSQL มีต้นทุนสูง

```text
Each PostgreSQL connection = a separate OS PROCESS, using ~5-10MB of memory.
  ✗ Opening a connection has overhead (process creation, auth, setup)
  ✗ Many connections (e.g. 1000s from a busy app) → huge memory use, contention
  ✗ Postgres has a max_connections limit (often ~100); exceeding it = errors
→ Opening/closing a connection per request, or holding thousands open, doesn't scale.
```

## โซลูชัน: connection pool

```text
A POOL maintains a small set of REUSABLE connections to Postgres.
Application requests BORROW a connection from the pool, use it, and RETURN it.
  ✓ Connections are reused (no per-request open/close overhead)
  ✓ Many app requests share a few DB connections (e.g. 10000 clients → 20 connections)
  ✓ Stays within max_connections, controls resource use → scales
```

## PgBouncer pooler ภายนอกมาตรฐาน

```text
PgBouncer sits BETWEEN the application and PostgreSQL — lightweight, efficient.
Pooling modes:
  Session   → a connection is assigned for the client's whole session
  Transaction → a connection is held only for the duration of a TRANSACTION (most
               efficient — connections returned between transactions; common choice)
  Statement → per-statement (most aggressive; limited)
→ Transaction pooling maximizes connection reuse for typical web apps.
```

## pooling เกิดขึ้นที่ไหน

```text
Application-level → many ORM/driver libraries have built-in pools (per app instance)
External pooler (PgBouncer) → a shared pool in front of Postgres (best for many app
  instances / serverless, where per-instance pools would still overwhelm the DB)
→ Serverless especially needs an external pooler (many short-lived instances).
```

## ทำไมจึงสำคัญ

connection pooling เป็นความรู้ที่จำเป็นสำหรับการรัน PostgreSQL **ในระดับขนาดใหญ่** เพราะ connection ของ PostgreSQL มีต้นทุนสูงเป็นเอกลักษณ์ (แต่ละตัวเป็น OS process แยกที่ใช้หน่วยความจำมาก) ดังนั้นการเข้าใจว่าทำไมจึงต้องการ pooling และมันทำงานอย่างไรจึงเป็นความรู้ระดับ senior ที่สำคัญสำหรับ deployment ที่มีประสิทธิภาพและขยายได้

ปัญหาหลักคือวิธีที่ตรงไปตรงมา การเปิด connection ต่อ request หรือการถือ connection หลายพันตัวเปิดไว้จากแอปพลิเคชันที่ยุ่ง ไม่ขยายกับ Postgres: connection มีต้นทุนสูง (หน่วยความจำต่อ process, overhead การสร้าง) และ Postgres มีขีดจำกัด `max_connections` (มักประมาณ 100) ที่ถูกเกินได้ง่าย ทำให้เกิด error และทรัพยากรหมด **connection pooling** แก้ปัญหานี้โดยรักษาชุด connection ที่นำกลับมาใช้ใหม่ได้ขนาดเล็กที่ request ของแอปพลิเคชันจำนวนมากใช้ร่วมกัน (ยืมและคืนมัน) ดังนั้น client หลายพันตัวสามารถได้รับบริการจาก connection ฐานข้อมูลไม่กี่สิบตัว ขจัด overhead ต่อ request และอยู่ในขีดจำกัด

การเข้าใจ **PgBouncer** (pooler ภายนอกมาตรฐาน) และ **pooling mode** ของมัน โดยเฉพาะ **transaction pooling** (ถือ connection เพียงช่วงเวลาของ transaction เพิ่มการนำกลับมาใช้ให้สูงสุด เป็นตัวเลือกที่พบบ่อยสำหรับ web app) เป็นความรู้เชิงปฏิบัติที่สำคัญ

การรู้ว่า **pooling เกิดขึ้นที่ไหน** (pool ระดับแอปพลิเคชันต่อ instance เทียบกับ pooler ภายนอกอย่าง PgBouncer สำหรับหลาย instance หรือ serverless) เป็นจุดสถาปัตยกรรมสำคัญ **serverless จำเป็นต้องใช้ pooler ภายนอกเป็นพิเศษ** เพราะ instance อายุสั้นจำนวนมากจะทำให้ Postgres ล้นด้วย connection (ปัญหาที่พบบ่อยและเกิดขึ้นจริง)

เนื่องจากการจัดการ connection ส่งผลโดยตรงต่อ scalability และความเสถียรภายใต้ load (และโมเดล process-per-connection ของ Postgres ทำให้สิ่งนี้รุนแรง) และเนื่องจาก pooling (โดยเฉพาะ PgBouncer ด้วย transaction pooling) เป็นโซลูชันมาตรฐานที่จำเป็น การเข้าใจ connection pooling ทั้งว่าทำไม Postgres จึงต้องการมัน, มันทำงานอย่างไร, PgBouncer และ mode ต่าง ๆ และข้อพิจารณาเรื่อง serverless จึงเป็นความรู้ระดับ senior ที่สำคัญต่อการดำเนินการ PostgreSQL ในระดับขนาดใหญ่ เป็นความกังวลที่มักวิกฤตสำหรับระบบ production ที่แยกแยะผู้ที่สามารถขยาย Postgres ได้ออกจากผู้ที่ประสบความล้มเหลวเรื่องขีดจำกัด connection