เลือก Database อย่างไรไม่ให้เสียใจ: คู่มือ SQLite, MySQL, MariaDB และ PostgreSQL จาก MVP ถึง SaaS

คำถามที่ทีมพัฒนาไทยถามกันบ่อยที่สุดข้อหนึ่งคือ "เริ่มโปรเจกต์ด้วย database ตัวไหนดี" คำตอบที่ถูกต้องกว่านั้นคือ database ที่เหมาะกับวันนี้ พร้อมทางถอยที่ไม่แพงเมื่อพรุ่งนี้เปลี่ยน เพราะงานวิจัยและ case study จำนวนมากชี้ตรงกันว่า ต้นทุนที่แท้จริงของการเลือก database ผิดไม่ได้อยู่ที่ค่า hosting รายเดือน แต่อยู่ที่ migration friction ที่สะสมทุกครั้งที่ระบบโต

บทความนี้สังเคราะห์จากข้อมูลราคาจริงของ Amazon RDS, Supabase และ Neon, benchmark ปี 2026 ระหว่าง MySQL 8.4 กับ PostgreSQL 17 และ case study ย้ายระบบจริง 3 องค์กร มาเป็นกรอบตัดสินใจแบบ lifecycle 4 ระยะ: MVP, Production, Enterprise และ SaaS

กรอบคิด 4 ระยะ: ความต้องการเปลี่ยน ต้นทุนก็เปลี่ยน

การมอง database เป็น "เลือกครั้งเดียวจบ" คือที่มาของปัญหา ในแต่ละระยะของผลิตภัณฑ์ น้ำหนักปัจจัยที่สำคัญไม่เท่ากัน

ประเด็นสำคัญคือกรอบนี้ไม่ได้บอกว่าต้องย้าย database ทุกระยะ แต่บอกว่า อย่าเลือกตัวที่ทำให้การย้ายในอนาคตแพงเกินจำเป็น

รู้จักตัวเลือกทั้งสี่อย่างที่ใช้งานจริง

SQLite: แชมป์ MVP ที่ไม่มี server

SQLite คือ embedded engine ที่เก็บข้อมูลทั้งหมดในไฟล์เดียว ไม่มี process แยก ไม่มี network latency ต้นทุนใกล้ศูนย์ นี่คือเหตุผลที่ Ruby on Rails ใช้เป็นค่า default มาตลอด แต่ข้อจำกัดก็ชัด: file-level locking ทำให้ concurrent write หลาย user พังได้ง่าย และแพลตฟอร์มอย่าง Heroku ไม่รองรับเลย ทีม Rails จำนวนมากจึงเริ่มด้วย SQLite แล้วย้ายไป PostgreSQL ตอน deploy จริง - ซึ่งเป็น pattern ที่ tools อย่าง pgloader ทำให้ใช้เวลาไม่กี่ชั่วโมง

MySQL: OLTP พื้นฐานที่แข็งแรง

MySQL ยังคงเป็นตัวเลือก default ของโลก LAMP และ SaaS ยุคแรก จุดแข็งคือ query ง่าย ๆ เร็วมาก - benchmark ปี 2026 พบว่า MySQL 8.4 ให้ throughput สูงกว่า PostgreSQL 17 ประมาณ 20-30% ใน simple SELECT และ ~30% ใน write-heavy workload สำหรับระบบ CRUD ธรรมดา นั่นแปลเป็น instance เล็กลงหนึ่งขนาดโดยตรง

MariaDB: drop-in replacement ของ MySQL

MariaDB fork จาก MySQL โดยทีมพัฒนาเดิม ใช้แทนกันได้เกือบทั้งหมด และบน Amazon RDS ราคาเท่ากับ MySQL เป๊ะ เหตุผลที่องค์กรย้ายไป MariaDB มักเป็นเรื่อง licensing, feature อย่าง parallel replication หรือทิศทาง governance - ไม่ใช่ราคา

PostgreSQL: ม้างานของ Enterprise และ SaaS

PostgreSQL คือ engine ที่ชนะขาดในสองด้าน: analytical query ซับซ้อนเร็วกว่า MySQL ถึง 2 เท่า (TPC-H) และ JSON document query เร็วกว่า 5-10 เท่า ด้วย JSONB + GIN index รวมถึง PostgreSQL 17 ลด memory ที่ VACUUM ใช้ลง 20 เท่า แก้จุดอ่อนหลักที่ถูกบ่นมานาน ทำให้ instance เล็กลงหรือ maintenance คาดเดาได้มากขึ้น

ความจริงเรื่องราคา: MySQL กับ PostgreSQL แทบไม่ต่างกัน

ข้อมูลราคา Amazon RDS (us-east-1) ปี 2026 เผยข้อเท็จจริงที่หลายทีมยังไม่รู้:

สรุป: ฐานราคาแทบ identical การตัดสินใจจึงไม่ควรอิงราคา แต่อิง workload สิ่งที่ต่างจริงคือมาตรการลดต้นทุน: Reserved Instance 1 ปี ลด ~29%, 3 ปีจ่ายหน้าลดกว่า 50% ขณะที่ extended support ของ version เก่า (MySQL 5.7, PostgreSQL 11) คิด ~$0.200/vCPU-ชม. - ไม่ upgrade ทันที can กินส่วนลดหมดตัว

นอกจาก RDS ยังมีสองโมเดลที่เปลี่ยนเกมสำหรับทีมเล็ก: Supabase Pro $25/เดือน รวม 8GB disk + 250GB egress + 100K MAU และ Neon serverless Postgres คิดตามใช้จริง ($0.106/CU-ชม. + $0.35/GB) ไม่มีขั้นต่ำ - เหมาะกับ traffic ผันผวนหรือ MVP ที่ยังไม่มีคนใช้มาก

3 case study ที่สอนว่า "ย้ายเมื่อไหร่ และเสียอะไร"

1. E-commerce ย้าย MySQL 8.0 ไป PostgreSQL 15

แพลตฟอร์มที่ query JSON และ join หลายตารางหนักขึ้นเรื่อย ๆ จน MySQL เริ่มตามไม่ทัน ทีมย้ายข้อมูล 120GB เสร็จใน ~3.5 ชั่วโมง ด้วยกระบวนการที่น่าเรียนรู้: ตรวจ schema สองฝั่งด้วย information_schema, นับ row ทุกตารางเทียบกัน และ checksum ทุกตาราง (MD5 ของคอลัมน์เรียงตาม id) ก่อนตัดระบบ ผลคือ JSON-heavy query เร็วขึ้นชัดเจนบน instance เดิม - เท่ากับได้ performance ฟรีเพราะ RDS ราคาเท่ากัน

2. SaaS 2,800 ลูกค้า ย้าย MySQL 5.7 ไป MariaDB 10.11 แบบ zero downtime

ทีมใช้ 3 เฟส: วิเคราะห์ compatibility ด้วย pt-upgrade (จับ query ที่ใช้ feature ที่ MariaDB ตัดทิ้ง เช่น query cache), ตั้ง parallel replication จาก binlog ให้ข้อมูล sync ตลอด แล้วค่อยๆ โยน traffic ผ่าน DNS-weighted routing ผลคือ ย้ายเสร็จโดยที่ลูกค้าไม่มีใครรู้ตัว - บทเรียนคือการย้ายใน lineage เดียวกัน (MySQL ไป MariaDB) ต้นทุนต่ำมากถ้าออกแบบกระบวนการดี

3. ทีม Rails ย้าย SQLite ไป PostgreSQL ตอนขึ้น Heroku

Pattern คลาสสิก: เพิ่ม gem pg, แก้ database.yml, รัน db:drop db:create db:migrate และถ้ามีข้อมูลจริงก็ pgloader ทิ้งชื่อฐานข้อมูลเข้าไป จบ นี่คือเหตุผลที่บอกว่า SQLite ไม่ใช่หลุมพราง - ตราบใดที่วางแผนทางถอยไว้ การเริ่มง่ายไม่ได้แพงเสมอไป

ข้อสอบใหญ่ของ SaaS: Multi-tenancy แบบไหน

เมื่อผลิตภัณฑ์กลายเป็น SaaS ที่มีลูกค้าหลายพันราย การออกแบบ multi-tenancy กำหนดต้นทุนระยะยาวมากกว่าเรื่อง engine เสียอีก คู่มือ Citus ของ Microsoft สรุปไว้ 3 แบบ:

• Database แยกต่อ tenant - แยกข้อมูลชัดที่สุด ง่ายต่อ backup/ลบตาม GDPR แต่พอ tenant เป็นพัน จะกลายเป็นฝูง database เล็ก ๆ ที่กิน resource รวมกันแพงและดูแลยาก
• Schema แยกต่อ tenant - ใช้ instance ร่วมแต่แยก logical เป็นทางสายกลาง เหมาะช่วงหลักสิบถึงหลักร้อย tenant
• Shared table + tenant_id - ทุก tenant อยู่ในตารางเดียว แยกด้วยคอลัมน์ tenant_id + sharding เป็นแบบที่ ประหยัด resource ที่สุดต่อ tenant และ cross-tenant analytics ทำได้เลย แลกกับวินัยในการเขียน query ที่ต้อง filter tenant เสมอ

สำหรับ SaaS ที่วางแผนโตเกิน 100 tenants, shared table + sharding บน PostgreSQL (ด้วย Citus extension หรือระบบที่ design ไว้ก่อน) คือคำตอบที่ research ชี้ตรงกัน

สรุป: checklist ตัดสินใจตามระยะ

• วันนี้คือ prototype จริง ๆ - ใช้ SQLite ได้เลย แต่มี discipline: อย่าใช้ feature เฉพาะ SQLite, เก็บ schema ไว้ใน migration เสมอ
• จะ deploy ให้คนใช้แล้ว - ข้ามไร้สาระไม่ได้: PostgreSQL บน free tier (RDS/Supabase/Neon) ต้นทุน $0 แต่ตัดปัญหา concurrency ทิ้งไปก่อน
• Query ง่าย เขียนเยอะ - MySQL เก่งเรื่องนี้จริง ใช้ได้สบาย แต่จับทางถอยด้วย ORM และ SQL มาตรฐาน
• มี analytics, JSON, หลาย tenant - PostgreSQL คือคำตอบที่ไม่ต้องคิดมาก: JSONB, extension ecosystem และ multi-tenancy pattern ที่ mature ที่สุด
• ติด MySQL อยู่แล้ว อยากได้ feature เพิ่ม - MariaDB ย้ายง่าย ราคาเท่าเดิม แต่ถ้าโจทย์คือ analytics/JSON ให้ไป PostgreSQL เลย
• ทุกกรณี - วางแผน upgrade version ไม่ให้ติด extended support เพราะค่าปรับกินส่วนลด reserved หมดตัว

บรรทัดสุดท้าย: ต้นทุน database ที่แท้จริงไม่ใช่ค่า instance แต่คือเวลาทีมและความเสี่ยงตอนย้าย เลือกตัวที่ ถูกพอสำหรับวันนี้ + ย้ายง่ายพอสำหรับวันหน้า และคุณจะไม่ต้องเสียใจทั้งสองทาง