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

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

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

PostgreSQL ให้ ACID transactions, joins, indexes และ query planner ที่สมบูรณ์ สำหรับหลายทีม นี่ก็เพียงพอแล้วสำหรับหลายปี

แต่ถ้าเราต้องการ global scale และ multi-Region architecture ล่ะ? Aurora DSQL ยังคงเข้ากันได้กับ PostgreSQL และเพิ่มโครงสร้างพื้นฐานแบบ serverless distributed แนวคิด 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

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

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

  1. ใช้ recursive CTE (WITH RECURSIVE) สำหรับการสำรวจแบบ hierarchy และ graph-like
  2. ใช้วิธีการแบบ extension-based (เช่น Apache AGE) สำหรับการสืบค้นแบบ property-graph
  3. ใช้ pgRouting (มักจะใช้กับ PostGIS) สำหรับปัญหา shortest-path และ graph traversal Supabase มีบทความที่ใช้งานได้จริงที่นี่: Postgres as a Graph Database: (Ab)using pgRouting

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

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

ต้องการ cronjobs, pub/sub และ background patterns ใช่ไหม? เราทำได้ ลิงก์ไปยังหัวข้อ

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

  1. งานแบบ Cron ด้วย pg_cron สำหรับงาน SQL ที่เกิดขึ้นเป็นระยะ (cleanup, rollups, sync jobs)
  2. pub/sub แบบ lightweight ด้วย LISTEN และ NOTIFY สำหรับเหตุการณ์แอปแบบ near-real-time
  3. worker queue ที่ทนทานด้วย FOR UPDATE SKIP LOCKED
  4. Outbox pattern: เขียนข้อมูลธุรกิจ + เหตุการณ์ใน transaction เดียวกัน จากนั้นเผยแพร่จาก outbox table อย่างปลอดภัย
  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 app ใช่ไหม? ใช่ เป็นไปได้เช่นกัน ลิงก์ไปยังหัวข้อ

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

  1. React frontend
  2. API layer (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. Core OLTP transactions พร้อมการรับประกัน ACID
  2. Complex relational joins ข้าม normalized models
  3. Window-function analytics ใน SQL
  4. Recursive hierarchy traversal ด้วย WITH RECURSIVE
  5. Background worker queues ด้วย FOR UPDATE SKIP LOCKED
  6. Materialized views สำหรับ precomputed reads
  7. Declarative partitioning สำหรับตารางขนาดใหญ่
  8. Row-level security สำหรับ multi-tenant isolation
  9. Logical replication และ CDC pipelines
  10. Cross-database federation ด้วย postgres_fdw
  11. Document workloads ผ่าน json และ jsonb
  12. JSON field indexing ด้วย GIN
  13. Full-text search และ ranking
  14. Event signaling ด้วย LISTEN และ NOTIFY
  15. Generated columns สำหรับ computed values
  16. API-driven SQL execution ผ่าน RDS Data API
  17. IAM-authenticated data access patterns บน AWS
  18. Lambda to Aurora integrations โดยไม่ต้องจัดการ connection pool
  19. GraphQL resolvers ที่สนับสนุนโดย PostgreSQL (หรือเส้นทาง pg_graphql ของ Supabase)
  20. Geospatial queries ด้วย PostGIS
  21. Graph modeling ผ่าน recursive SQL patterns
  22. Property graph extensions เช่น Apache AGE
  23. Vector similarity search ด้วย pgvector
  24. Hybrid AI workloads: metadata + embeddings + transactions
  25. Global, serverless PostgreSQL-compatible deployments ด้วย Aurora DSQL

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

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

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

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

  1. เลือก pure 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. NoSQL-like JSON
  3. การเข้าถึง API
  4. รูปแบบ Graph
  5. Vector search
  6. โครงสร้างพื้นฐานที่เข้ากันได้กับ PostgreSQL แบบกระจายทั่วโลก

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