PostgreSQL คืออะไร

PostgreSQL คือ relational database ที่เก็บข้อมูลเป็น table และให้คุณอธิบายความสัมพันธ์ระหว่าง table เหล่านั้นได้ บนรากฐานนี้ยังเพิ่มการรับประกันความถูกต้องที่แข็งแกร่งและความยืดหยุ่นระดับที่ไม่ธรรมดา สองอย่างรวมกันคือคำอธิบายว่าทำไม PostgreSQL จึงเป็นตัวเลือกเริ่มต้นของโปรเจกต์จำนวนมาก บทเรียนนี้ปูแนวคิดหลักไว้ให้ เพื่อให้ส่วนที่เหลือของคอร์สมีพื้นฐานที่มั่นคง

relational model

ใน relational model ข้อมูลอยู่ใน table โดย table คือ table ที่มีชื่อ แต่ละ column มีชื่อและ type ที่ตายตัว และแต่ละ row คือหนึ่ง record ที่มีค่าสำหรับทุก column table ของลูกค้าอาจมี column สำหรับ id, ชื่อ และอีเมล โดยแต่ละ row คือลูกค้าหนึ่งราย

พลังนั้นมาจาก ความสัมพันธ์ (relationship) row ใน table หนึ่งชี้ไปยัง row ใน table อีกตัวได้ด้วยการเก็บ key ของ row นั้นไว้ เช่น table orders เก็บ customer_id ของลูกค้าที่สั่งซื้อในแต่ละ order ซึ่งเชื่อมโยง table ทั้งสองเข้าด้วยกัน แผนภาพด้านล่างแสดง table สอง table ที่สัมพันธ์กันในลักษณะนี้

flowchart LR
  subgraph customers
    C1[id: 1, name: Mira]
    C2[id: 2, name: Devon]
  end
  subgraph orders
    O1[id: 100, customer_id: 1]
    O2[id: 101, customer_id: 1]
    O3[id: 102, customer_id: 2]
  end
  O1 -->|customer_id references id| C1
  O2 -->|customer_id references id| C1
  O3 -->|customer_id references id| C2

table สองอันที่สัมพันธ์กันด้วย key

id ที่ระบุ row ได้แบบไม่ซ้ำเรียกว่า primary key ส่วน column ใน table อีกตัวที่ชี้กลับมาหา row นั้นคือ foreign key คุณจะได้ออกแบบ table และ key ในโมดูลถัดไป แล้วค่อยเอามารวมกันด้วย join ทีหลัง สำหรับตอนนี้สิ่งที่ต้องจำคือความสัมพันธ์ถูกเก็บเป็นค่าธรรมดา ไม่ใช่ pointer ที่ซ่อนอยู่

การรับประกันแบบ ACID

PostgreSQL รับประกันว่าข้อมูลของคุณยังคงถูกต้องผ่านการล่ม ข้อผิดพลาด และการเข้าถึงพร้อมกัน คำสัญญาเหล่านั้นสรุปได้ด้วยคำย่อ ACID

ตัวอักษร	คุณสมบัติ	หมายความว่าอะไรสำหรับคุณ
A	Atomicity	กลุ่มของการเปลี่ยนแปลงจะเกิดขึ้นทั้งหมดหรือไม่เกิดเลย
C	Consistency	ทุกการเปลี่ยนแปลงทำให้ฐานข้อมูลยังคงปฏิบัติตามกฎที่ตั้งไว้
I	Isolation	transaction ที่เกิดพร้อมกันจะไม่ทำให้กันและกันเสียหาย
D	Durability	เมื่อ commit แล้ว การเปลี่ยนแปลงจะอยู่รอดผ่านการล่ม

หน่วยที่นำพาการรับประกันเหล่านี้คือ transaction — กลุ่มของ statement ที่ถูกปฏิบัติเสมือนเป็นการทำงานแบบทั้งหมดหรือไม่ทำเลยหนึ่งเดียว transaction จะมีโมดูลเต็มในภายหลัง สำหรับตอนนี้ให้รู้ไว้ว่า PostgreSQL จะไม่ทิ้งข้อมูลของคุณไว้ในสภาพที่เปลี่ยนไปเพียงครึ่งเดียว

MVCC ในหนึ่งบรรทัด

PostgreSQL บรรลุ isolation ผ่าน MVCC หรือ multi-version concurrency control: แทนที่จะ lock row ให้ผู้อ่าน PostgreSQL เก็บ row ไว้หลายเวอร์ชันเพื่อให้ผู้อ่านเห็น snapshot ที่สอดคล้องกันในขณะที่ผู้เขียนทำงาน และผู้อ่านไม่เคยขวางผู้เขียน

ความสามารถในการขยาย (Extensibility)

สิ่งที่ทำให้ PostgreSQL แตกต่างอย่างแท้จริงคือขยายความสามารถได้ไกลแค่ไหน คุณไม่ได้ติดอยู่กับเมนูฟีเจอร์ที่ตายตัว

type ที่หลากหลายและกำหนดเองได้ — นอกเหนือจากตัวเลขและข้อความ Postgres มาพร้อมกับ date, array, geometric type, network address และอื่น ๆ และคุณสามารถนิยาม type ของคุณเองได้
JSONB — เก็บและสร้าง index ให้เอกสาร JSON จริงภายใน column ได้ ผสมผสานสไตล์ relational และ document ไว้ในฐานข้อมูลเดียว
Extension — แพ็กเกจแบบเสียบใช้งานได้ทันทีเพิ่มความสามารถทั้งชุด เช่น postgis สำหรับข้อมูลทางภูมิศาสตร์ หรือ pg_trgm สำหรับการจับคู่ข้อความแบบ fuzzy ติดตั้งได้ด้วยคำสั่ง CREATE EXTENSION เพียงคำสั่งเดียว

ความยืดหยุ่นนี้หมายความว่า PostgreSQL instance เดียวมักจะแทนที่เครื่องมือเฉพาะทางหลายตัวได้ ทำให้ stack ของคุณเรียบง่ายขึ้น

เมื่อใดที่ PostgreSQL เหมาะสม

PostgreSQL เป็นตัวเลือกเริ่มต้นที่แข็งแกร่งสำหรับเกือบทุกแอปพลิเคชันที่เก็บข้อมูลแบบมีโครงสร้างและใส่ใจเรื่องความถูกต้อง: backend ของเว็บและมือถือ, analytics, เครื่องมือภายใน และอื่น ๆ PostgreSQL โดดเด่นเมื่อข้อมูลของคุณมีความสัมพันธ์ที่ชัดเจน เมื่อคุณต้องการ transaction ที่ไว้ใจได้ หรือเมื่อคุณต้องการ engine เดียวที่จัดการ JSON, search และงาน geospatial ได้ด้วย

จะเหมาะน้อยลงเมื่อคุณต้องการ in-memory cache ล้วน ๆ สำหรับข้อมูลชั่วคราว หรือ engine เฉพาะทางสำหรับ workload สุดขั้วเพียงอย่างเดียว เช่น time-series ที่อัตราการรับเข้าข้อมูลมหาศาล — แม้แต่ในกรณีนั้น extension มักจะช่วยปิดช่องว่างได้ สำหรับโปรเจกต์ส่วนใหญ่อย่างท่วมท้น การหยิบ PostgreSQL ขึ้นมาก่อนเป็นตัวเลือกที่ปลอดภัยและยืนยง

เคล็ดลับและข้อควรระวัง

คิดในรูปของ table และความสัมพันธ์ตั้งแต่แรก การออกแบบข้อมูลให้ดีตั้งแต่เนิ่น ๆ ช่วยลดความเจ็บปวดในภายหลัง
primary key ระบุ row ได้แบบไม่ซ้ำ ส่วน foreign key ใน table อีกตัวชี้กลับมาที่ row นั้น
ACID ไม่ใช่เวทมนตร์ที่คุณเปิดสวิตช์ — เปิดอยู่ตลอดเวลา ผ่านการทำงานของ transaction
หยิบ JSONB มาใช้เมื่อส่วนหนึ่งของข้อมูลของคุณเป็น schemaless อย่างแท้จริง แต่ให้เก็บส่วนที่มีโครงสร้างไว้ใน column ปกติ
ก่อนที่จะรับเอาฐานข้อมูลเฉพาะทางแยกต่างหากมาใช้ ให้ตรวจดูว่ามี extension ของ PostgreSQL ที่ครอบคลุมความต้องการนั้นอยู่แล้วหรือไม่

ข้อแลกเปลี่ยน

ตัวเลือก	Benefit	Cost
Self-hosted PostgreSQL	ควบคุม config, extension และ version ได้เต็มที่	ต้องดูแล backup, patching และ tuning เอง
Managed service เช่น RDS หรือ Supabase	ลดภาระ ops, ได้ backup และ failover มาให้	ค่าใช้จ่ายสูงขึ้นและถูกจำกัด extension บางตัว
ใช้ extensibility ของ Postgres (JSONB, extension)	engine เดียวรองรับหลาย workload	schema และ query ซับซ้อนขึ้นถ้าใช้พร่ำเพรื่อ
ฐานข้อมูลเฉพาะทางแยกต่างหาก	ประสิทธิภาพที่ดีที่สุดสำหรับงานนั้นโดยเฉพาะ	เพิ่มจำนวนระบบที่ต้องดูแลและ sync ข้อมูล

ข้อผิดพลาดที่พบบ่อย

คิดว่า PostgreSQL “ก็เหมือน MySQL” — ทั้งสองเป็น relational database ก็จริง แต่ MVCC, type system และพฤติกรรม transaction ต่างกันพอสมควร อย่าย้าย mental model มาตรง ๆ โดยไม่เช็คก่อน
เลือก managed provider โดยไม่เช็ค version หรือ extension ที่รองรับ — บาง provider lock version ไว้เก่ากว่าหรือไม่เปิด extension ที่คุณต้องการ (เช่น postgis) เช็ค compatibility ก่อนผูกมัดกับ provider
ประเมินภาระงานของการ self-host ต่ำเกินไป — backup, monitoring, patching และ scaling เป็นงานต่อเนื่อง ไม่ใช่ตั้งค่าครั้งเดียวจบ

💡 ตัวอย่างจากของจริง

Instagram — สเกล PostgreSQL แบบ vanilla ให้รองรับผู้ใช้หลายร้อยล้านคนได้ด้วยเทคนิค sharding ที่ layer แอปพลิเคชัน แสดงให้เห็นว่า Postgres ธรรมดาไปได้ไกลแค่ไหนเมื่อออกแบบ schema และ scaling strategy ดี

Supabase — สร้าง developer platform ทั้งชุดขึ้นบน PostgreSQL โดยใช้ extensibility ของ PostgreSQL (realtime, auth, storage) เป็นแกนหลัก แทนที่จะสร้างฐานข้อมูลของตัวเองใหม่