สมมติว่าเรากำลังจะเริ่มระบบใหม่ในวันนี้ เราควรเลือกฐานข้อมูลใดเป็นอันดับแรก?

คำตอบของผมง่ายๆ คือ: PostgreSQL เริ่มต้นด้วย SQL ใช้ SQL ต่อไป เพิ่มความสามารถเมื่อจำเป็น โดยไม่ต้องเปลี่ยนฐานข้อมูลทุกไตรมาส

เริ่มต้นจาก SQL แล้วไปที่ Aurora DSQL ลิงก์ไปยังหัวข้อ

PostgreSQL รองรับธุรกรรมแบบ ACID, joins, indexes และ query planner ที่ครบถ้วน สำหรับหลายทีม นี่ก็เพียงพอแล้วสำหรับหลายปี

แต่ถ้าต้องการรองรับระบบทั่วโลกและสถาปัตยกรรมแบบ multi-Region ล่ะ? Aurora DSQL ยังคงเข้ากันได้กับ PostgreSQL และเพิ่มโครงสร้างพื้นฐานแบบ serverless ที่กระจายตัว แนวคิด SQL แบบเดิม แต่มีขอบเขตการปรับขนาดที่ใหญ่ขึ้น

ต้องการ NoSQL ใช่ไหม? PostgreSQL ก็ทำได้เช่นกัน ลิงก์ไปยังหัวข้อ

jsonb ของ PostgreSQL ช่วยให้สามารถทำงานแบบ document-style ได้ในฐานข้อมูลเดียวกัน คุณสามารถเก็บข้อมูลกึ่งโครงสร้าง เพิ่ม JSON indexes และยังคง join กับ relational tables ได้

ดังนั้น ใช่แล้ว เมื่อมีคนพูดว่า “ตอนนี้เราต้องการ NoSQL” ในหลายกรณี PostgreSQL ก็เพียงพอแล้ว

ต้องการการเข้าถึง API ใช่ไหม? RDS Data API ทำได้ ลิงก์ไปยังหัวข้อ

ด้วย Aurora + RDS Data API เราสามารถเรียกใช้ SQL ผ่าน HTTPS API calls โดยมีการรวม IAM และ Secrets Manager สิ่งนี้เหมาะสำหรับระบบ serverless และ event-driven ที่การเชื่อมต่อ DB ที่ใช้งานนานไม่เหมาะสม

และหากคุณต้องการแพลตฟอร์มแบ็กเอนด์ที่สมบูรณ์รอบ PostgreSQL, Supabase เป็นอีกทางเลือกหนึ่งที่ได้รับความนิยม: PostgREST/GraphQL APIs, auth, realtime, storage และ dashboard บน Postgres

ต้องการฐานข้อมูลกราฟใช่ไหม? PostgreSQL ก็ทำได้ ลิงก์ไปยังหัวข้อ

มีอย่างน้อยสามวิธี:

  1. ใช้ recursive CTE (WITH RECURSIVE) เพื่อสำรวจข้อมูลแบบลำดับชั้นและกราฟ
  2. ใช้ extension เช่น Apache AGE สำหรับคิวรีแบบ property graph
  3. ใช้ pgRouting ซึ่งมักทำงานร่วมกับ PostGIS สำหรับหาเส้นทางสั้นที่สุดและสำรวจกราฟ Supabase มีบทความที่ใช้งานได้จริงที่นี่: Postgres as a Graph Database: (Ab)using pgRouting

ต้องการ vector search ใช่ไหม? PostgreSQL ก็ทำได้ ลิงก์ไปยังหัวข้อ

ด้วย pgvector, PostgreSQL สามารถจัดเก็บ embeddings และเรียกใช้ similarity search ได้ สิ่งนี้เพียงพอสำหรับการแนะนำ, semantic search และการดึงข้อมูลแบบ RAG ในขณะที่ transactional metadata ยังคงอยู่ในที่เดียวกัน

ต้องการ cron jobs, pub/sub และงานเบื้องหลังใช่ไหม? PostgreSQL ก็ทำได้ ลิงก์ไปยังหัวข้อ

นี่เป็นอีกหนึ่งด้านที่ผู้คนมักจะเพิ่มระบบพิเศษเร็วเกินไป PostgreSQL มีองค์ประกอบพื้นฐานที่มีประโยชน์อยู่แล้ว:

  1. งานตามกำหนดเวลาด้วย pg_cron สำหรับ SQL ที่รันเป็นระยะ เช่น cleanup, rollups และ synchronization
  2. pub/sub น้ำหนักเบาด้วย LISTEN และ NOTIFY สำหรับเหตุการณ์ของแอปแบบเกือบเรียลไทม์
  3. คิว worker ที่ทนทานด้วย FOR UPDATE SKIP LOCKED
  4. รูปแบบ Outbox: เขียนข้อมูลธุรกิจและเหตุการณ์ในธุรกรรมเดียวกัน แล้วเผยแพร่จากตาราง outbox อย่างปลอดภัย
  5. การลองใหม่และ dead-letter ด้วยคอลัมน์สถานะ (pending, processing, failed) และตัวนับจำนวนครั้ง
  6. การทำงานแบบ idempotent โดยใช้ unique keys, constraints และ advisory locks
  7. เส้นทาง Supabase: การเปลี่ยนแปลง Postgres สามารถไหลเข้าสู่ Realtime subscriptions สำหรับการอัปเดตไคลเอ็นต์

เรายังคงต้องการ Kafka, SQS หรือ EventBridge ในบางครั้งหรือไม่? ใช่ แน่นอน แต่สำหรับงาน product workloads จำนวนมาก การเริ่มต้นจากรูปแบบ PostgreSQL นั้นง่ายกว่าและเร็วกว่า

ต้องการแบ็กเอนด์สำหรับแอป React ใช่ไหม? PostgreSQL ก็ทำได้ ลิงก์ไปยังหัวข้อ

รูปแบบทั่วไป:

  1. ส่วน frontend ด้วย React
  2. เลเยอร์ API ด้วย Node/Express, Lambda หรือ GraphQL resolver
  3. Aurora PostgreSQL หรือ Aurora DSQL
  4. RDS Data API เสริมสำหรับการเรียกใช้ SQL แบบ HTTP

อ้างอิง: React App video

ที่ได้รับความนิยมอีกอย่าง: React + Supabase client + Supabase Auth + Postgres database

25 สิ่งที่คุณสามารถทำได้ด้วย PostgreSQL (และตัวเลือกที่เข้ากันได้กับ Aurora PostgreSQL) ลิงก์ไปยังหัวข้อ

  1. ธุรกรรม OLTP หลักพร้อมการรับประกันแบบ ACID
  2. การ join เชิงสัมพันธ์ที่ซับซ้อนข้ามโมเดลที่ผ่าน normalization
  3. การวิเคราะห์ด้วย window functions ใน SQL
  4. การสำรวจลำดับชั้นแบบ recursive ด้วย WITH RECURSIVE
  5. คิว worker เบื้องหลังด้วย FOR UPDATE SKIP LOCKED
  6. Materialized views สำหรับผลลัพธ์ที่คำนวณไว้ล่วงหน้า
  7. Declarative partitioning สำหรับตารางขนาดใหญ่
  8. Row-level security สำหรับแยกข้อมูลแบบ multi-tenant
  9. Logical replication และ CDC pipelines
  10. การเชื่อมโยงข้ามฐานข้อมูลด้วย postgres_fdw
  11. งานแบบ document ผ่าน json และ jsonb
  12. การสร้างดัชนีฟิลด์ JSON ด้วย GIN
  13. Full-text search และการจัดอันดับผลลัพธ์
  14. การส่งสัญญาณเหตุการณ์ด้วย LISTEN และ NOTIFY
  15. Generated columns สำหรับค่าที่คำนวณ
  16. การรัน SQL ผ่าน API ด้วย RDS Data API
  17. รูปแบบเข้าถึงข้อมูลบน AWS ที่พิสูจน์ตัวตนด้วย IAM
  18. การเชื่อมต่อ Lambda กับ Aurora โดยไม่ต้องจัดการ connection pool
  19. GraphQL resolvers ที่ใช้ PostgreSQL เป็นฐาน หรือใช้ pg_graphql ของ Supabase
  20. คิวรีข้อมูลภูมิศาสตร์ด้วย PostGIS
  21. การสร้างโมเดลกราฟด้วยรูปแบบ recursive SQL
  22. ส่วนขยาย property graph เช่น Apache AGE
  23. การค้นหา vector ตามความคล้ายคลึงด้วย pgvector
  24. งาน AI แบบผสมที่รวม metadata, embeddings และธุรกรรม
  25. การ deploy ระบบแบบ serverless ทั่วโลกที่เข้ากันได้กับ PostgreSQL ด้วย Aurora DSQL

PostgreSQL vs Supabase (เปรียบเทียบอย่างรวดเร็ว) ลิงก์ไปยังหัวข้อ

ส่วนนี้สำคัญเพราะผลิตภัณฑ์เหล่านี้ไม่ใช่ผลิตภัณฑ์ประเภทเดียวกัน:

  1. PostgreSQL = เอนจินฐานข้อมูล
  2. Supabase = แพลตฟอร์มที่ใช้ PostgreSQL เป็นฐานข้อมูลหลัก พร้อมเครื่องมือ API/auth/realtime/storage

ดังนั้น “PostgreSQL vs Supabase” มักจะไม่ใช่การเลือกอย่างใดอย่างหนึ่งที่ยาก ในทางปฏิบัติ:

  1. เลือก PostgreSQL โดยตรงเมื่อต้องการควบคุมระบบระดับล่างอย่างเต็มที่และออกแบบแพลตฟอร์มเอง
  2. เลือก Supabase เมื่อคุณต้องการการส่งมอบผลิตภัณฑ์ที่เร็วขึ้นด้วยเครื่องมือสำหรับนักพัฒนาที่จัดการรอบ PostgreSQL
  3. เลือก Aurora PostgreSQL/Aurora DSQL เมื่อลำดับความสำคัญของคุณคือการดำเนินงานแบบ AWS-native, การรวม IAM และสถาปัตยกรรมที่จัดการแบบ multi-Region

นี่คือ GenAI ใช่ไหม? ใช่ ลิงก์ไปยังหัวข้อ

“นี่คือ GenAI ใช่ไหม? ใช่ ดังนั้นที่นี่เราจะจินตนาการว่า PostgreSQL สามารถทำอะไรได้บ้างในอนาคต”

นี่คือการคาดเดาร่วมกันของเรา ทั้งของคุณและของผม:

  1. สถาปัตยกรรมฐานข้อมูลในหน่วยความจำ: ข้อมูลที่ใช้งานบ่อยที่สุดและการดำเนินการส่วนใหญ่อยู่ในหน่วยความจำ โดยมีเลเยอร์แบ็กเอนด์ที่ทนทานคล้าย S3 สำหรับการคงอยู่และการกู้คืน
  2. ฐานข้อมูลทั่วโลกขนาดใหญ่: พฤติกรรม active-active แบบ multi-Region ใกล้เคียงกับ native เป็นค่าเริ่มต้น ไม่ใช่กรณีพิเศษระดับพรีเมียม
  3. Agent runtime ภายใน PostgreSQL: AI agents โฮสต์เป็น database procedures/functions ใกล้กับข้อมูล พร้อมการรับประกัน transaction และการควบคุมนโยบาย

อาจจะไม่ทั้งหมดนี้จะเกิดขึ้นในรูปแบบนี้เป๊ะๆ แต่ทิศทางชัดเจน: PostgreSQL ยังคงดูดซับงานใหม่ๆ โดยไม่สูญเสียรากฐาน SQL

ข้อสรุปสุดท้าย ลิงก์ไปยังหัวข้อ

ในทางปฏิบัติ ทีมส่วนใหญ่ไม่จำเป็นต้องมีฐานข้อมูลห้าแบบสำหรับรูปแบบข้อมูลห้าแบบ PostgreSQL บวกกับตัวเลือกที่เข้ากันได้กับ Aurora PostgreSQL ครอบคลุมงานส่วนใหญ่แล้ว:

  1. SQL
  2. JSON แบบ NoSQL
  3. การเข้าถึงผ่าน API
  4. รูปแบบกราฟ
  5. Vector search
  6. โครงสร้างพื้นฐานที่เข้ากันได้กับ PostgreSQL และกระจายทั่วโลก

ดังนั้น หากคุณถามผมว่าจะเริ่มต้นที่ไหน: เริ่มต้นด้วย PostgreSQL จากนั้นค่อยเพิ่มความซับซ้อนเมื่อคุณต้องการจริงๆ