ฉากเปิด: สตาร์ทอัพไทย 3 คน ที่ launch product ด้วย Supabase + 0 DBA#

ลองนึกภาพ scenario นี้ครับ — เป็นสตาร์ทอัพสมมติ แต่ pattern แบบนี้เกิดจริงในวงการปี 2025

ทีม 3 คน นั่งที่ co-working ย่านอารีย์ Founder มาจากสาย business Dev คนเดียวเขียน frontend + backend ทั้งหมด Designer ทำ UI/UX + ดูแล social ไม่มี CTO ไม่มี DBA ไม่มี DevOps ไม่มีใครต้องตื่นตอนตี 3

product ของพวกเขาคือ SaaS เล็กๆ สำหรับร้านอาหาร — จัดการ reservation + เก็บข้อมูลลูกค้าประจำ user หลัก 10,000 ราย peak ตอนเย็นวันศุกร์ ~500 concurrent user off-peak ตอนตี 3 ~5 user ระบบ build ด้วย stack นี้

• Frontend — Next.js บน Vercel (free tier ขั้นแรก)
• Backend logic — Supabase Edge Functions
• Database — Supabase Postgres
• Auth — Supabase Auth
• File storage — Supabase Storage (เก็บรูปร้าน, รูปเมนู)
• Realtime — Supabase Realtime (โต๊ะถูกจองปุ๊บ user คนอื่นเห็นทันที)

ค่าใช้จ่ายเดือนแรก = 0 บาท ทั้งหมดอยู่ใน free tier ของ Supabase + Vercel พอเริ่มมี paid customer ค่อยขยับขึ้น Pro tier ราว $25/เดือน ไม่มี server ให้ดูแล ไม่มี backup script ให้เขียน ไม่มี SSL certificate ให้ renew ไม่มี security patch ให้ตามอุดทุกสัปดาห์

ทีนี้ลองเปรียบเทียบกับ stack เดียวกัน ถ้า build ปี 2014 ดูครับ

• Database server — AWS RDS MySQL db.t3.medium, ~$60/เดือน
• Cache layer — Redis บน EC2, ~$30/เดือน
• Search — Elasticsearch cluster, ~$150/เดือน
• Auth — เขียน auth logic เอง + เก็บ session ใน Redis
• File storage — S3, ~$10/เดือน
• Realtime — ตั้ง WebSocket server เอง บน EC2 อีกตัว, ~$30/เดือน
• DBA part-time — อย่างน้อย 20 ชม./สัปดาห์, ~50,000 บาท/เดือน
• DevOps — ตั้ง backup, monitoring, alerting, scaling, security patch — อีก 20 ชม./สัปดาห์
• On-call rotation — Dev ต้องถือมือถือสุดสัปดาห์ เพราะ database ล่มได้ทุกเมื่อ

stack 2014 = ทุนเริ่มต้นอย่างน้อย 100,000 บาท/เดือน + มนุษย์ 3-5 คนดูแล stack 2025 = 0 บาท + 0 DBA ระบบเดียวกัน ทำของเดียวกัน นี่แหละที่หลายคนเรียกว่า “democratization ของ infrastructure” — เครื่องมือที่เคยใช้งบสตาร์ทอัพ Series A ทั้งรอบ ตอนนี้นักพัฒนาคนเดียวก็มีใช้

ทำไมเป็นแบบนี้ได้? ต้องเข้าใจวิวัฒนาการของ database ในยุค cloud ก่อนครับ — มันมี 4 ระดับชัดเจน

Database evolution ในยุค cloud — 4 ระดับ#

ตั้งแต่ปี 2006 ที่ AWS เปิดตัว EC2 วิธีที่บริษัทเก็บ database เปลี่ยนไป 4 ระดับ ยิ่งระดับสูง ยิ่ง “ไม่ต้องดูแล” + ยิ่ง “จ่ายตามใช้” มาดูทีละชั้น

ทำไม Serverless DB เปลี่ยนเกมของสตาร์ทอัพ#

ก่อนยุค serverless การเริ่ม build product ที่มี database มีต้นทุนตั้งต้นชัดเจน RDS instance เล็กสุดยังอยู่ที่ $15-30/เดือน ต้องจ่ายตั้งแต่วันแรกแม้จะยังไม่มี user สักคน MVP fail — จ่ายเปล่า MVP ติด — ต้อง provision เผื่อตอน viral จ่ายแพงตอน traffic ยังไม่มี

serverless พลิกสมการนี้ทั้งหมด มี 3 ผลกระทบหลักที่เปลี่ยนเกมของวงการ

ผลกระทบที่ 1: Cost เริ่มต้น = 0 — free tier ของ Supabase, Neon, Cloudflare D1, DynamoDB ครอบคลุม MVP ของสตาร์ทอัพส่วนใหญ่ได้สบาย founder ไม่ต้องมี burn rate สำหรับ infrastructure กล้าทดลองมากขึ้น เพราะ “ลองแล้ว fail ก็ไม่เสียเงิน”

ผลกระทบที่ 2: ไม่ต้องจ้าง DBA — เงินเดือน DBA full-time ในไทยปี 2025 อยู่ที่ 80,000-200,000 บาท/เดือน สำหรับสตาร์ทอัพ Seed round นี่คือ 1 ใน 3 ของ runway ทั้งเดือนเลยนะครับ serverless database ไม่ต้องการ DBA — Supabase/Neon/AWS ดูแลให้หมด เงินตรงนี้เอาไปจ้าง engineer ที่สร้าง product feature แทนได้

ผลกระทบที่ 3: scale อัตโนมัติเมื่อ viral — เมื่อก่อน ถ้า product ติด TechCrunch แล้ว user ทะลัก admin ต้องตื่นตอนตี 3 มา resize instance อาจจะต้อง migrate database ตอน traffic peak ที่สุด serverless จะ auto-scale ขึ้นเอง founder นอนหลับได้ bill อาจจะแพงขึ้น แต่ระบบไม่ล่ม

ตรงนี้สำคัญสำหรับผู้บริหารครับ — serverless DB ไม่ใช่แค่เทคโนโลยีใหม่ มันคือ business model ใหม่ของ infrastructure จากเดิม “จ่ายตามขนาดที่ provision” กลายเป็น “จ่ายตามที่ใช้จริง” เปลี่ยน CAPEX เป็น OPEX ที่ปรับขนาดได้ตาม revenue

ก่อนจะไปต่อ — ถ้ายังไม่แม่นเรื่อง serverless / cloud เป็นพื้นฐาน แนะนำกลับไปอ่าน IT Foundation EP.04 — Architectures (มี section serverless อธิบายตั้งแต่หลักคิด) + CyberSec Foundation EP.32 — Cloud Shared Responsibility (อธิบาย IaaS/PaaS/SaaS/FaaS ใครรับผิดชอบอะไรในแต่ละชั้น) ก่อน EP.05 ตอนนี้จะลงลึกเรื่อง database ของ serverless ต่อจากตรงนั้น

ทีนี้ serverless database คนเดียวยังไม่เปลี่ยนเกมเต็มที่ครับ สิ่งที่เปลี่ยนเกมจริงๆ คือตอนที่ database ถูกรวมกับ Auth + Storage + Realtime + Functions ในชุดเดียว — สิ่งที่วงการเรียกว่า BaaS

The “BaaS” Rise — Backend-as-a-Service ที่รวมหลายอย่าง#

ปี 2010-2020 backend ของ web/mobile app ทั่วไปประกอบด้วยส่วนพวกนี้

• Database (Postgres/MySQL/MongoDB)
• Authentication (login, signup, forgot password)
• File storage (รูป, video)
• Realtime updates (chat, notification, live data)
• Background jobs (ส่งอีเมล, generate report)

ทั้งหมดนี้นักพัฒนาต้อง assemble เอง — เช่า server install ทีละตัว เชื่อมเข้าด้วยกัน ใช้เวลา 2-4 สัปดาห์ก่อน feature แรกของ product จะเขียนได้

BaaS (Backend-as-a-Service) คือบริการที่รวมทั้งหมดนี้ในแพ็กเดียว install ครั้งเดียว ใช้ได้ครบ มาดู major players กัน

Edge Database เจาะลึก#

ใน CAP theorem ของ EP.04 เราเรียนว่า เมื่อ database กระจายตัว ต้องเลือกระหว่าง consistency กับ availability Edge database คือคำตอบใหม่ของวงการที่บอกว่า — ในกรณีของ read-heavy workload (อ่านบ่อยกว่าเขียน 100 เท่า) เรา replicate ข้อมูลกระจายทั่วโลก ให้ user อ่านจาก server ใกล้ตัวที่สุด แล้ว write กลับไปที่ primary region ทีหลัง

มาดู major players กัน

PlanetScale ตัด free tier 2024 — บทเรียนเรื่อง vendor lock-in#

ปี 2021-2024 PlanetScale คือสิ่งที่นักพัฒนาทั่วโลกหลงรัก มันคือ MySQL serverless ที่มี 3 จุดเด่นที่ไม่มีใครเหมือน

1. Branching — เหมือน Git เลยครับ คุณ branch database สำหรับ feature ใหม่ test ได้ merge กลับ นักพัฒนาคุ้นกับ git workflow รัก feature นี้มาก
2. Schema migration ปลอดภัย — ระบบช่วย review schema change ก่อน deploy
3. Free tier ที่กว้าง — 5 GB storage + 1 พันล้าน row read/เดือน ฟรี ครอบคลุม MVP แทบทุกตัว

สตาร์ทอัพหลายพันรายเลือก PlanetScale เป็น default database side project นับไม่ถ้วน build บนมัน ทุกคนคิดว่า “ฟรีตลอดไป” เพราะบริษัทขายเงินจาก enterprise tier

แล้วต้นปี 2024 — PlanetScale ประกาศ ตัด free tier ทั้งหมด user ทุกคนต้อง migrate ขึ้น paid plan ขั้นต่ำ $39/เดือน หรือ migrate ออกภายใน **30 วัน** side project ที่มี user 100 คน อยู่ดีๆ ต้องเลือก จ่าย$39/เดือนสำหรับของที่เคยฟรี หรือย้าย database ทั้งหมดไปที่อื่นภายในเดือนเดียว

อ้าวเฮ้ย ผลคือสตาร์ทอัพและ developer ทั่วโลกเดือดร้อนมาก มี blog post เป็นพันโพสต์เล่า migration story ไป Neon, Supabase, PostgreSQL บน RDS บางเคสที่ schema ใหญ่ + ใช้ feature เฉพาะของ PlanetScale (เช่น branching workflow) ใช้เวลา migrate เป็นเดือน + เสีย feature บางตัวไปด้วย

Pricing Model ที่เปลี่ยนเกม — Pay per Request vs Pay per Server-hour#

หัวใจของ serverless database จริงๆ ไม่ใช่ technology ครับ มันคือ pricing model มาดูตารางเปรียบเทียบ cost จริงของ side project ที่มี traffic 10,000 request/เดือน + storage 500 MB

ดูตัวเลขแล้วน่าตกใจครับ side project เดียวกัน option แรกจ่าย $15/เดือน option สุดท้ายจ่าย$0/เดือน ต่างกัน 100% ไม่ใช่ 100 บาท

ทำไมต่างขนาดนี้? เพราะ pricing model ต่างกัน

• Pay per server-hour (option 1, 2) — server เปิด 24/7 จ่าย 24/7 ไม่ว่าจะมี user หรือไม่ side project ที่มี user เข้า 100 ครั้ง/วัน server idle 99% ของเวลา จ่ายเปล่า
• Pay per request (option 3, 4, 5, 6) — request 0 = bill 0 request 10,000 = bill ตามจริง มี user 100 ครั้ง/วัน bill ตามนั้น ไม่ขาด ไม่เกิน

ความหมายในภาคปฏิบัติ — pricing model แบบนี้ทำให้ “experiment” ฟรีจริงๆ นักพัฒนาเปิด side project 10 ตัว 9 ตัวไม่มีใครใช้ bill รวมยังเป็น $0 1 ตัวที่ติด bill ค่อยขึ้นตาม revenue

ก่อน serverless การ experiment 10 ไอเดียมี cost คงที่ $150-300/เดือน นักพัฒนาเลยกล้าทดสอบแค่ 1-2 ไอเดียเต็มที่ ปัจจุบัน ทดสอบ 10 ไอเดียเสีย$0 Volume ของการทดลองในวงการเพิ่มขึ้น 5-10 เท่า และจากการทดลองที่เพิ่มขึ้นนี้แหละคือที่มาของ product ดีๆ จำนวนมากในยุคปัจจุบัน

มุมผู้บริหาร — pricing model นี้เปลี่ยน economics ของการสร้างสตาร์ทอัพ burn rate ของ Seed round ที่เคยใช้กับ infrastructure 30-40% เหลือ 5-10% เงินที่เหลือเอาไปหา product-market fit จ้าง engineer ทำ marketing แทน นี่คือเหตุผลที่จำนวนสตาร์ทอัพรอบ Seed ในตลาดทั่วโลกเพิ่มขึ้นเรื่อยๆ ตั้งแต่ปี 2020

มุมผู้บริหาร — signal 4 อย่างที่บอกว่าควรย้ายจาก RDS ไป Serverless#

ตรงนี้เขียนเฉพาะสำหรับเจ้าของกิจการ / ผู้บริหารที่กำลังจะตัดสินใจครับ ถ้าทีม IT เสนอย้ายจาก RDS (หรือ self-hosted database) ไป serverless check 4 signal นี้ดู

Signal 1: Traffic ไม่สม่ำเสมอ (peak/off-peak ต่างกันมาก) — ถ้า peak ตอนกลางวัน 1,000 req/วินาที off-peak ตอนตี 3 = 5 req/วินาที RDS ต้อง provision เผื่อ peak (เปลือง 90% ของเวลา) serverless จ่ายตามจริง ประหยัด 60-80%

Signal 2: ไม่มี DBA full-time — ถ้าทีมไม่มี DBA + ไม่ได้วางแผนจ้าง serverless ลดภาระ ops ลง 90% RDS ยังต้องมีคน config + monitor + tune query

Signal 3: Product ยังไม่ proven (อยู่ใน MVP/PMF stage) — ถ้ายังหา product-market fit อยู่ serverless ให้ economic flexibility fail แล้วไม่เสียเงินเปล่า ติดแล้ว scale ได้ทันที

Signal 4: ระบบมี downtime ก็ได้ (ไม่ใช่ banking-critical) — serverless บางตัวมี cold start latency 1-3 วินาทีตอนตื่นจาก idle ถ้าระบบยอมรับได้ก็ OK ถ้าเป็นระบบเทรดหุ้นที่ทุก ms มีค่า ไม่เหมาะ

ส่วน 4 signal ที่ ไม่ควรย้าย

• ระบบ enterprise ที่ traffic predictable + sustained สูง (RDS ถูกกว่า serverless ตอน traffic เต็ม)
• Compliance บังคับให้ data อยู่บน infrastructure ที่ควบคุมเองได้
• ระบบที่ใช้ feature เฉพาะของ database engine (เช่น stored procedure ซับซ้อน) ที่ serverless ตัดออก
• ทีมเก่งและพอใจกับ stack ปัจจุบัน — อย่าเปลี่ยนเพื่อ buzzword

ปิดบท — Database Era ที่กำลังเข้า#

EP.05 จบที่นี่ครับ 5 ยุคของ database ตลอด Part 1 สรุปได้สั้นๆ ตามนี้

1. 1960s-70s — Hierarchical: ห้องสมุดแบบต้นไม้ ขยายยาก
2. 1970s-80s — Relational Revolution: ตารางที่ JOIN ได้ + SQL กลายเป็นมาตรฐานวงการ
3. 1980s-90s — ACID + Enterprise Backbone: Oracle/SQL Server ครองธนาคาร สายการบิน ระบบบัญชี
4. 2000s-2010s — NoSQL + Big Data: CAP theorem + 4 ตระกูล NoSQL + Hadoop + Polyglot Persistence
5. 2020s — Cloud-Native + Serverless: DBaaS → Serverless → Edge, pricing model เปลี่ยนจาก server-hour เป็น per-request

ตลอด 5 ยุคนี้ pattern ที่ซ้ำคือ เทคโนโลยีไม่แพ้เทคโนโลยี — แพ้ economic model ที่เปลี่ยนเกม Hierarchical ไม่แพ้เพราะ technical inferior แพ้เพราะ relational + SQL ลด cost ของ developer ลงมหาศาล Self-hosted database ไม่แพ้ serverless เพราะ technical แย่ แพ้เพราะ serverless ลด cost ของ infrastructure + DBA ลงเหลือ near-zero

Part 1 จบที่นี่ครับ แต่ EP.05 ทั้งหมดที่คุยมา เราพูดถึง database จากภายนอก — เลือกตัวไหน host ที่ไหน จ่ายยังไง ยังไม่ได้เข้าใจว่าภายใน database มันทำงานยังไง ทำไม index ทำให้ query เร็วขึ้น 1,000 เท่า schema ที่ออกแบบดีต่างกับที่ออกแบบไม่ดียังไง transaction ที่รับประกัน ACID ทำได้ยังไง

Part 2 (EP.06-08) จะลงลึกตรงนี้ — schema, normalization, keys ใน EP.06 ต่อด้วย index + query optimization ใน EP.07 ปิดท้ายที่ transaction + concurrency control ใน EP.08 ตรงนี้เป็นเรื่องที่ engineer ต้องรู้เต็มๆ แต่ผู้บริหารที่อ่านจบจะเห็นว่าทำไม “DBA เก่ง” ถึงแพง

แล้วหลังจาก Part 2 Part 3 จะกลับมาที่มุม “เลือก storage ตามขนาด” อีกครั้ง ตั้งแต่เว็บส่วนตัว (database-less ที่ blog นี้ใช้อยู่) ไปจนถึง enterprise ที่ใช้ database 5-10 ตัวพร้อมกัน ทุกขนาดมีสูตรของมันเอง

→ EP.06 — Schema, Normalization, Keys (เร็วๆ นี้)