ฉากเปิด: เปิดร้านอาหารโดยไม่มีครัว#

ลองนึกภาพร้านอาหารร้านหนึ่งที่กรุงเทพปี 2026 — เปิดมาขายดีมาก คนเข้าวันละหลายร้อยคน พอเดินเข้าไปหลังร้าน — ไม่มีครัว ไม่มีเชฟ ไม่มีเตา ไม่มีตู้เย็น ไม่มีคนล้างจาน มีแค่เคาน์เตอร์รับออเดอร์กับเด็กเสิร์ฟ 2 คน

อาหารทุกจานมาจากครัวกลางที่อยู่อีกซีก เช่าเป็นชั่วโมง คนล้างจานจ้างเป็นรายชิ้น วัตถุดิบสั่งทีต่อทีตอนลูกค้าสั่ง ค่าเช่าครัวเดือนนี้ — ขายมากจ่ายมาก ขายน้อยจ่ายน้อย เดือนไหนไม่เปิดร้านเลย จ่ายใกล้ศูนย์

ฟังดูบ้าใช่ไหม แต่นี่คือสิ่งที่ SaaS startup ปี 2026 ทำกันอยู่จริงๆ — แค่เปลี่ยน “ครัว” เป็น “database server” และเปลี่ยน “เชฟ” เป็น “DBA”

ลอง scenario สมมติ — สตาร์ทอัพไทยทีมหนึ่ง 3 คน founder ดูธุรกิจ + ขาย, dev เขียน code, designer ทำ UI เปิด SaaS ทำเครื่องมือจัดการนัดหมายให้คลินิกเล็กๆ หลังเปิด 8 เดือน — มีคลินิกใช้ 800 แห่ง user รวมในระบบราว 10,000 คน รายได้เดือนละ 2 แสนบาท

สแตกที่ทีมนี้ใช้

• Frontend — Vercel host เว็บ Next.js
• Backend + Database + Auth + Storage — Supabase ตัวเดียว
• Payment — Stripe (international) + Omise (สำหรับลูกค้าไทยที่จ่ายผ่าน QR PromptPay)
• Email — Resend ส่ง notification
• DNS + CDN + WAF — Cloudflare

5 บริการ ไม่มี server ที่ทีมต้องดูแลเลยสักตัว ไม่มี DBA ไม่มีคนนอน on-call ตอนตี 2 ค่าใช้จ่ายรวมทั้งสแตก — เดือนละ ~$50 (ราว 1,800 บาท)

นี่ไม่ใช่ scenario สมมติเฉยๆ — pattern นี้คือ default ของ SaaS เกิดใหม่ทั่วโลกตอนนี้ EP.11 จะเจาะว่า — เครื่องมือพวกนี้คืออะไร แบ่งเป็นกี่ family เลือกตัวไหนตอนไหน และ vendor lock-in ที่ต้องเห็นตั้งแต่ day 1

(ใครยังไม่ค่อยเก็ตว่า “serverless database” คืออะไร แนะนำย้อนไป EP.05 — ยุค 2020s: Cloud-Native + Serverless ก่อนสักนิด EP.05 เล่ามุมประวัติ EP.11 จะลงรายละเอียดของแต่ละตัวว่าใช้ทำอะไร เมื่อไหร่ใช้ตัวไหน)

Backend-as-a-Service (BaaS) — ครัวกลางที่รวมทุกอย่างในตัวเดียว#

เริ่มจาก family ใหญ่สุดก่อน — Backend-as-a-Service หรือย่อว่า BaaS หลักคิดคือ — แทนที่ทีมจะต้อง assemble database + auth + file storage + serverless function + push notification เองทีละชิ้น — ใช้ service เดียวที่รวมทุกอย่างมาให้แล้ว

เทียบกับร้านอาหารก็คือ — แทนที่จะเปิดครัว + จ้างเชฟ + ซื้อเตา + จ้างคนล้างจานเอง — เช่า “ครัวพร้อมพนักงาน” รายเดือน มี kitchen manager ดูแล มีคนล้างจานสำรอง มีของสดส่ง

ปี 2026 มี 4 ตัวที่ทีม startup เลือกใช้บ่อยสุด — แต่ละตัวเหมาะกับทีมคนละแบบ

Serverless Postgres — เน้นเฉพาะ database#

family ที่สอง — Serverless Postgres ต่างจาก BaaS ตรงที่ตัวพวกนี้โฟกัสที่ database อย่างเดียว ไม่มี auth ไม่มี storage ไม่มี function — มีแต่ Postgres ที่ scale อัตโนมัติ + จ่ายตามใช้

เคสที่เหมาะคือ — ทีมที่มี backend ของตัวเองอยู่แล้ว (อาจจะ Node.js / Python / Go) ต้องการแค่ database ที่ไม่ต้องดูแล server หรือทีมที่อยาก mix-and-match — ใช้ Postgres ตัวนี้กับ auth ตัวอื่น (เช่น Clerk) กับ storage อีกตัว (เช่น R2)

มีตัวที่น่าสนใจ 3 ตัวในตลาด

Serverless MySQL — มีน้อยกว่า Postgres เยอะ#

ในวงการ serverless database ปี 2026 — Postgres ครองตลาดเกือบเบ็ดเสร็จ MySQL มีตัวเลือกน้อยกว่า + แต่ละตัวมีปัญหาของตัวเอง

มี 2 ตัวที่ควรรู้

Edge Database — สำหรับ global app#

family ที่สี่ — Edge Database แนวคิดคือ — แทนที่ database จะอยู่ที่ region เดียว (เช่น Singapore) แล้วผู้ใช้ทั่วโลกต้องวิ่งเข้ามาหา — กระจาย database ไปอยู่ทุก region ใกล้ผู้ใช้

ผู้ใช้ไทยเรียก database ที่กรุงเทพ ผู้ใช้ยุโรปเรียก database ที่แฟรงก์เฟิร์ต ผู้ใช้อเมริกาเรียก database ที่ Virginia response time ต่ำกว่า 50 ms ทุกที่ในโลก

มี 5 ตัวที่ควรรู้

• Cloudflare D1 — SQLite distributed บน edge ของ Cloudflare ฟรีในระดับ MVP รวมเข้ากับ Cloudflare Workers ลื่น
• Turso — libSQL (fork ของ SQLite) ที่ replicate ไปทุก region spec คล้าย D1 แต่อยู่นอก ecosystem ของ Cloudflare
• Upstash — Redis serverless เน้น cache + session + queue จ่ายตาม request ไม่ใช่ตามเวลา server เปิด
• Convex — backend-as-a-service ที่เน้น reactive query (ข้อมูลเปลี่ยน — UI update เอง) competitor ตรงๆ ของ Firebase
• Xata — กล่าวข้างบนแล้ว แต่ Xata distributed Postgres ด้วย

เคสที่เหมาะกับ Edge Database:

• App ที่ user กระจายทั่วโลก (ไม่ใช่แค่ผู้ใช้ไทย)
• Real-time feature ที่ latency สำคัญ (chat, multiplayer game, live cursor)
• Mobile app ที่ต้องโต้ตอบเร็วในทุก region

เคสที่ไม่จำเป็นต้องใช้: App ที่ user อยู่ region เดียว (เช่น SaaS เฉพาะลูกค้าไทย) กระจาย database ทั่วโลกไม่ช่วยอะไร — เปลือง budget เปล่าๆ

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

ตรงนี้สำคัญที่สุดในเรื่อง business model ของ SaaS เกิดใหม่ มันคือเหตุผลจริงๆ ที่ทำไม founder ปี 2026 ถึงกล้า “ship อะไรก็ได้ก่อน”

แบบเดิม — Pay per Server-hour

• เช่า AWS RDS (managed MySQL) instance เล็กสุด = ~$15/เดือน
• ขนาดกลาง = ~$50-100/เดือน
• traffic เป็น 0 ก็จ่ายเหมือนเดิม เพราะ server เปิดรอตลอด

แบบใหม่ — Pay per Request

• Supabase free tier = $0/เดือน ถ้าใช้ไม่เกิน limit
• Upstash = จ่ายต่อ command ที่ส่งจริง ($0.20 per 100K requests)
• Neon = จ่ายต่อ second ที่ database active (auto-pause เมื่อไม่มี request)
• ตอน MVP ไม่มี user → ค่า database ใกล้ $0
• พอมี user → ค่าเพิ่มตามใช้จริง, scale linear กับ revenue

ผลที่เปลี่ยนเกมคือ — **cost of failure = $0** ก่อนปี 2020 ถ้า founder อยากลองไอเดีย 5 ตัว — ต้องจ่ายค่า hosting + database ของทั้ง 5 ตัวต่อเนื่องเป็นเดือนๆ ปี 2026 — launch product 5 ตัวที่ไม่ดัง = ค่าใช้จ่ายใกล้$0 ดัง 1 ตัว = ค่า scale อัตโนมัติตามรายได้

นี่คือเหตุผลที่ “indie hacker” / “solopreneur” / “micro-SaaS” กลายเป็นกระแสในวงการ เพราะ economic friction ของการลอง — เกือบหมดไปแล้ว

มุมผู้บริหาร: ถ้าทีมยังจ่ายค่า database server แบบเก่า (RDS เปิดตลอดทั้งที่ MVP ยังไม่มี traffic) — คุณกำลังเสีย runway ฟรี ลอง migrate MVP ขึ้น serverless tier ก่อน (free tier ของ Supabase / Neon / Upstash ครอบคลุม MVP ส่วนใหญ่ได้สบาย) ค่อย upgrade เมื่อมี traffic จริง

Vendor Lock-in Trap — ที่ต้องเห็นตั้งแต่ day 1#

ทุกอย่างฟังดูสวยงาม — จนกระทั่งวันที่ vendor เปลี่ยน price หรือปิด service

Case 1: Firebase price hike ที่เกิดซ้ำๆ

ในวงการมี horror story หลายเคสของ startup ที่ build บน Firebase 3-5 ปี แล้ว Google ปรับ pricing ขึ้น 5-10 เท่ากะทันหัน เพราะ Firestore เป็น proprietary NoSQL ที่ไม่มี SQL standard ให้ยึด — migrate ออกหมายถึงเขียน application ใหม่เกือบทั้งหมด ค่า migrate มักจะเป็นหลักล้านบาท + เวลา 6-12 เดือน

Case 2: PlanetScale ปิด free tier ปี 2024

ที่กล่าวไปแล้ว — ลูกค้า free tier เป็นพันรายต้อง migrate ใน 30 วัน คนที่ build MVP บน free tier โดยคิดว่ามันจะอยู่ตลอด — เจอ wake-up call ที่ปวดหัว

บทเรียน 4 ข้อจาก 2 case นี้

1. ใช้ standard SQL ไม่ใช่ vendor-specific

ถ้าเลือก Postgres-compatible (Supabase, Neon, Xata, RDS, Aurora) — schema ของคุณเป็น standard SQL ที่ migrate ไปอยู่ Postgres ที่ไหนในโลกก็ได้ ถ้าเลือก Firestore — schema คุณคือ Firestore ตลอดไปจนกว่าจะเขียนใหม่

2. มี migration plan ตั้งแต่ day 1

แม้จะใช้ vendor ที่ดูมั่นคง — ทีมควรเขียนเอกสารสั้นๆ ตั้งแต่วันแรกว่า “ถ้าวันหนึ่งต้องย้ายออก จะย้ายไปไหน ใช้ tool อะไร ใช้เวลาเท่าไร” ไม่ต้องลงรายละเอียด แค่ให้รู้ว่ามี exit path ที่ห้ามคือ “ไม่เคยคิดเลยจนวันที่ vendor บอกว่าราคาขึ้น 10 เท่า”

3. Multi-cloud strategy (ถ้า business critical)

สำหรับ SaaS ที่โตขึ้นมา ($1M+ ARR) — พิจารณา production บน cloud หนึ่ง + DR (disaster recovery) backup บน cloud อีกเจ้า ค่าเพิ่มไม่เยอะมาก ลด vendor risk เยอะ

4. Data export ทุกเดือน

ทำ automated job export database backup ออกมาเก็บไว้ที่ object storage ของอีก cloud ถ้า vendor ปิดบริการพรุ่งนี้ — อย่างน้อยข้อมูลของคุณอยู่ในมือ service ส่วนใหญ่มี API export อยู่แล้ว เขียน cron job เรียกเดือนละครั้งก็พอ

มุมผู้บริหาร: vendor lock-in ไม่ใช่เหตุผลที่จะ “ไม่ใช้ serverless” serverless เร็ว ถูก scale อัตโนมัติ — ข้อดีเหล่านี้เกินคุ้มสำหรับ MVP แต่การไม่คิดเรื่อง exit path ตั้งแต่วันแรก = สมัครใจแบกความเสี่ยงระยะยาว คุยเรื่องนี้กับทีมตั้งแต่ก่อน commit สแตก

เคสจริง: Typical Thai SaaS Stack 2026#

ขมวดทุกอย่างที่คุยมาให้เห็นเป็น diagram จริงๆ ที่ทีม SaaS ไทย 3 คนใช้กัน

1
┌─────────────────────────────────────────────────┐
2
│                   USER (browser)                 │
3
└──────────────────────┬──────────────────────────┘
4
                       │
5
                       ▼
6
┌─────────────────────────────────────────────────┐
7
│  Frontend: Vercel / Cloudflare Pages            │
8
│  (Next.js / Astro / SvelteKit)                  │
9
└──────────────────────┬──────────────────────────┘
10
                       │
11
       ┌───────────────┼───────────────┐
12
       ▼               ▼               ▼
13
┌──────────┐    ┌──────────┐    ┌──────────┐
14
│ Database │    │   Auth   │    │  Storage │
15
│ Supabase │    │ Supabase │    │ Supabase │
16
│ Postgres │    │  / Clerk │    │   / R2   │
17
└──────────┘    └──────────┘    └──────────┘
18
       │
19
       ▼
20
┌──────────┐    ┌──────────┐    ┌──────────┐
21
│  Cache   │    │ Payment  │    │  Email   │
22
│ Upstash  │    │  Stripe  │    │ Resend   │
23
│  Redis   │    │  / Omise │    │/SendGrid │
24
└──────────┘    └──────────┘    └──────────┘
25
       │
26
       ▼
27
┌──────────┐
28
│Analytics │
29
│Cloudflare│
30
│/PostHog  │
31
└──────────┘

ค่าใช้จ่ายรวมตามขนาด user

เทียบกับสแตกเดิม (RDS + EC2 + ELB + S3) — ที่จุดเดียวกันมักจะแพงกว่า 3-5 เท่า + ต้องจ้าง DevOps engineer 1 คนเงินเดือนหลายแสน

Myth-busting: “BaaS = ดีสำหรับ MVP, ปัญหาตอน scale”#

มี myth ที่เห็นบ่อยในวงการ — “serverless / BaaS = เหมาะกับ MVP, พอ scale แล้วต้องย้ายออกอยู่ดี” ผมอยากบอกว่า — มันไม่จริงในปี 2026

Fact 1: มี SaaS ที่ scale ถึง 100K+ user รัน production อยู่บน Supabase ตอนนี้ โครงสร้างไม่ได้พังตอนโตขึ้น — มัน scale ตามที่ Postgres scale ได้ (ซึ่งคือมหาศาลถ้า optimize ดี)

Fact 2: Notion ใช้ Postgres แอปจัดการ doc ที่มี user เป็น 100 ล้านคน — ใช้ Postgres เป็น database หลัก (เคย shard เอง แต่ไม่ใช้ proprietary NoSQL) Postgres ไม่ใช่ database สำหรับ MVP เท่านั้น

Fact 3: Vercel เองรัน 10M+ requests/day บน serverless stack ของตัวเอง บริษัทที่ทำ infra ให้คนอื่น ใช้ serverless infra เอง = signal ที่แรงพอควร

คำถามจริงไม่ใช่ “scale ได้ไหม” — แต่เป็น “scale แบบไหน”

• Read-heavy + write-light (blog, content site, doc system, e-commerce catalog) → serverless OK ทุกระดับ
• Write-heavy + low latency strict (high-frequency trading, real-time multiplayer game) → managed Postgres / dedicated cluster อาจจำเป็น
• Massive concurrent write (Twitter-scale ingestion) → ต้องใช้ specialized stack

ถ้า business ของคุณไม่ได้อยู่ใน 2 case หลังนี้ — serverless รับได้สบาย ส่วนใหญ่ของ SaaS ในโลกอยู่ใน case แรก

มุมผู้บริหาร — เมื่อไหร่ควรย้ายออกจาก Serverless กลับไป self-hosted#

แม้ว่า serverless จะ default ของ SaaS เกิดใหม่ — มี 4 signal ที่บอกว่าถึงเวลาควรพิจารณา self-host

1. Cost — เมื่อ database cost > server cost แบบ self-hosted

Pricing model ของ serverless เป็น “ถูกตอน scale น้อย ยอมเสียพรีเมียมตอน scale ใหญ่” จุด break-even มักจะอยู่ที่ scale ใหญ่มาก ($10K-30K/เดือนของค่า database) ถ้าทีมเริ่มเห็นบิล serverless เข้าใกล้เลขนี้ — เริ่มประเมินได้ว่า self-host บน dedicated server จะถูกกว่า (รวมค่า DBA แล้ว)

2. Vendor Risk — vendor lock-in ที่ business ไม่ยอมรับ

เช่น — บริษัทที่จะ exit (ขายให้รายใหญ่ / IPO) ผู้ซื้อมัก due diligence เรื่อง vendor dependency ถ้าทุกอย่างผูกกับ vendor เดียว — valuation อาจถูกลด self-host ส่วน critical จะให้ control มากกว่า

3. Compliance — data residency requirement ที่ vendor ไม่รองรับ

บางอุตสาหกรรม (financial services, healthcare ในบาง country) บังคับว่าข้อมูลต้องอยู่ใน data center ของบริษัทเอง / ใน region เฉพาะ ถ้า serverless vendor ไม่มี region ที่ตรง requirement — ต้อง self-host

4. Performance — workload ที่ต้องการ specific tuning ที่ managed service ไม่ให้

managed service ทุกตัว trade flexibility เพื่อ ease of use ถ้า workload ต้องการ tune Postgres parameter พิเศษ custom extension ที่ vendor ไม่รองรับ hardware spec ที่ vendor ไม่มี — self-host ได้ flexibility ที่ต้องการ

สรุปง่ายๆ: SaaS เกิดใหม่ปี 2026 = serverless first, self-host last resort เริ่มที่ serverless เพื่อ ship เร็ว scale ถึงจุดที่ economics กลับด้าน หรือ requirement บังคับ — ค่อยพิจารณา migrate ไม่ใช่ทำกลับด้าน

ปิดบท — Stack เล็กๆ พลังมหาศาล#

EP.11 จบที่นี่ครับ SaaS เกิดใหม่ปี 2026 ใช้สแตกที่ 10 ปีก่อนยังไม่มีอยู่จริง — Supabase + Vercel + Stripe + Cloudflare + Resend ทีม 3 คนรัน user 10,000 ได้เดือนละพันกว่าบาท เรื่องที่เคยต้องจ้าง DBA + DevOps + sysadmin เต็มเวลา — ตอนนี้ click-deploy ได้ใน 5 นาที

แต่ — ของฟรีในวงการไม่มีจริง trade-off คือ vendor lock-in ที่ทีมต้องเห็นตั้งแต่ day 1 PlanetScale ปี 2024, Firebase price hike — เป็นเสียงเตือนดังๆ ว่าไม่มี vendor ไหนที่อยู่ตลอดกาลใน free tier เดิม

มาถึงตรงนี้ผมคุยมา 11 ตอนแล้ว ทุกตอนสมมติฐานเดียวกัน — ทีมขนาดเล็ก app ขนาดเล็ก-กลาง choose 1 database ที่เหมาะที่สุด

แต่พอขึ้นไปอีก scale หนึ่ง — enterprise ที่มีพนักงาน 50,000 คน ลูกค้าเป็นล้านบริษัท — สมมติฐานนี้ก็พัง เพราะ enterprise ไม่ใช้ database ตัวเดียว — ใช้ 7-10 ตัวพร้อมกัน ตัวละหน้าที่ Postgres สำหรับ order, Cassandra สำหรับ log, Elasticsearch สำหรับ search, Neo4j สำหรับ recommendation, Snowflake สำหรับ analytics, Redis สำหรับ cache EP.12 เราจะคุยเรื่องนี้กัน — pattern ที่วงการเรียกว่า Polyglot Persistence

→ EP.12 — มุม Enterprise: Polyglot Persistence