ฉากเปิด: นั่งอยู่บนเครื่องบิน ไม่มีเน็ต — แต่ Notion ยังเปิดได้#

ลองนึกภาพ scenario นี้

คุณกำลังบินจากกรุงเทพไปโตเกียว ที่นั่งชั้นประหยัด Wi-Fi บนเครื่องราคา $20 ตัดสินใจไม่จ่าย เปิด laptop กด Notion… เปิดได้ครับ เห็น workspace เห็นทุกบทความ เห็นทุก task เขียนต่อได้ทันที พิมพ์ไปเรื่อยๆ จนเครื่องลง

พอลงเครื่อง เปิดเน็ตที่สนามบินนาริตะ — ไม่ต้องกดปุ่ม sync ไม่ต้องอะไรเลย Notion เห็นเน็ตปุ๊บ ก็ส่งงานที่คุณเขียนบนเครื่องบินขึ้น cloud พร้อมกับดึงงานที่เพื่อนร่วมทีมแก้ในออฟฟิศตอนคุณบินอยู่ — ทุกอย่าง merge กันได้เองโดยไม่ขัดแย้ง

คำถามคือ — ตอนนั่งอยู่บนเครื่องบินไม่มีเน็ต ข้อมูลคุณอยู่ที่ไหน?

EP.09 เราคุยเรื่อง “เว็บที่ไม่มี database” — content static เสิร์ฟจาก edge ไม่มี database ตรงกลาง EP.10 จะ flip มุมตรงข้าม — แทนที่จะไม่มี database เลย เรา ย้าย database มาอยู่บนเครื่องของผู้ใช้ทุกคน แล้วใช้ cloud เป็นแค่จุดนัดพบเวลามีเน็ต

ฟังดูแปลก แต่ที่จริง pattern นี้คุณใช้อยู่ทุกวันอยู่แล้ว แค่ไม่รู้ว่าเบื้องหลังเรียกว่าอะไร

SQLite — database ที่ใช้เยอะที่สุดในโลก แต่ไม่มีใครรู้จัก#

ก่อนเข้าเรื่อง local-first ผมขอแนะนำตัวเอกของบทนี้ก่อน — SQLite

ลอง quiz เล็กๆ — database อะไรที่ deploy เยอะที่สุดในโลก? คนส่วนใหญ่นึกถึง MySQL, Oracle, PostgreSQL, MongoDB คำตอบจริงคือ SQLite และไม่ใช่ชนะเฉยๆ — มันชนะแบบขาดลอยจน database อื่นรวมกันยังไม่ถึงครึ่ง

ลองนับคร่าวๆ ว่า SQLite อยู่ที่ไหนบ้าง:

• มือถือทุกเครื่องในโลก — iOS ใช้ SQLite เป็นเบื้องหลังของ Core Data, Android ใช้ SQLite เก็บ contacts, SMS, call log iPhone/Android เครื่องไหนๆ ก็มี SQLite ติดตั้งมาแล้วอย่างน้อย 5-10 ฐานข้อมูล
• Browser ทุกตัว — Chrome, Firefox, Safari, Edge ใช้ SQLite เก็บ history, cookie, bookmark, IndexedDB ทุก tab ที่คุณเปิดอยู่ตอนนี้มี SQLite ทำงานอยู่ใต้ฝา
• Apple ecosystem — Mail.app, iMessage, Photos library, Safari, App Store ทั้งหมดเก็บข้อมูลใน SQLite
• Embedded systems — TV ดิจิทัลตามบ้าน, in-flight entertainment บนเครื่องบิน, ATM ของธนาคาร, GPS ในรถ, set-top box ของเคเบิลทีวี ทั้งหมดมี SQLite อยู่ข้างใน
• Software ที่คุณใช้รายวัน — Adobe Lightroom, Skype, Dropbox client, 1Password, Bear, Things, Evernote — เก็บ metadata ใน SQLite

รวมๆ แล้วมีคนประเมินว่า SQLite รันอยู่บน device เกิน 1 ล้านล้านเครื่อง (trillion) ทั่วโลก เป็น “the most widely deployed database in the world” — ยังไม่มีคู่แข่งที่ใกล้เคียง

แล้วทำไมไม่มีใครพูดถึงล่ะ?

คำตอบคือ — เพราะมัน embedded มันไม่ได้รันเป็น server ที่ต้องตั้งชื่อ ตั้ง port ตั้ง user/password ไม่มีคนเป็น DBA ดูแล มันแค่… ฝังอยู่กับ app เงียบๆ ทำงานของมันไป จนคุณไม่รู้ว่ามันมีตัวตน

SQLite ต่างจาก server database ยังไง#

9 EP ที่ผ่านมา เราคุยเรื่อง database แบบ “server” หมด — MySQL, PostgreSQL, MongoDB, Oracle ทุกตัวเป็น process ที่ต้องเปิดทิ้งไว้ตลอดเวลา รับ connection จาก app คนละเครื่อง ทำงานเป็นบริการกลาง

SQLite ไม่ใช่แบบนั้น มันต่างกันคนละโลก:

1. Single file — database ทั้งตัวคือไฟล์เดียว นามสกุล .db หรือ .sqlite ขนาด 100KB ถึง 100GB ก็ได้ จะ backup ก็ copy ไฟล์ จะย้ายเครื่องก็ส่งไฟล์ผ่าน USB ได้เลย ไม่มี dump/restore ให้ปวดหัว

2. Embedded — ไม่มี server process — SQLite เป็น library ที่ link เข้ากับ app ตอน compile app เรียก SQLite เหมือนเรียก function ปกติ ไม่ต้องเปิด network connection ไม่มี TCP/IP, ไม่มี port, ไม่มี authentication — เพราะไม่มีใครเข้ามาจาก network ได้อยู่แล้ว

3. Zero-configuration — ไม่มีไฟล์ config ให้แก้ ไม่มีไฟล์ user/password ไม่ต้องตั้ง memory size ไม่ต้องตั้ง connection pool — copy ไฟล์มา open ก็ใช้ได้ ใหม่หรือเก่า มือถือหรือ desktop เหมือนกันหมด

4. Cross-platform single file — ไฟล์ .db ตัวเดียวกัน อ่านได้ทั้งบน Windows, Mac, Linux, iOS, Android, browser (ผ่าน WebAssembly) ไม่มี endianness ไม่มี version mismatch ที่ขยับเครื่องแล้วเปิดไม่ออก

อุปมาง่ายๆ:

• Server database (MySQL, PostgreSQL) เหมือน ตู้เซฟในธนาคาร — ของคุณอยู่ในนั้น แต่จะดูทีต้องเดินทางไปธนาคาร แสดง ID เซ็นชื่อ รอเจ้าหน้าที่หยิบให้ ปลอดภัย ใช่ แต่ทุกการเข้าถึงต้องผ่าน gatekeeper
• SQLite เหมือน ตู้เก็บของในห้องคุณเอง — เปิดเมื่อไหร่ก็ได้ หาของได้ทันที ไม่ต้องขอใคร แต่ก็ไม่ได้ออกแบบให้คน 100 คนเข้ามาเปิดพร้อมกัน

ไม่ใช่ว่าตัวไหนดีกว่าตัวไหนนะ — เป็น tool คนละงาน SQLite ออกแบบมาเพื่อ “1 app, 1 device, 1 user” server DB ออกแบบเพื่อ “หลาย app, หลาย device, หลาย user พร้อมกัน”

มุมผู้บริหาร: ถ้า product ของคุณมีคนใช้ทีละคน (mobile app, desktop app, browser extension) — อาจไม่ต้องการ database server เลย SQLite ทำงานได้ดีกว่า ถูกกว่า ง่ายกว่ามาก

The Local-first Movement — ปรัชญาของยุคใหม่#

ปี 2019 research lab ชื่อ Ink & Switch ออก paper ชื่อ “Local-first software: You own your data, in spite of the cloud” paper นี้กลายเป็น manifesto ของขบวนการที่กำลังโตขึ้นเรื่อยๆ ในวงการ software design

ก่อนเข้าหลักการ ขอ context ก่อน — ยุค 2010s เป็นยุคของ cloud-first Google Docs, Dropbox, Slack, Notion, Figma ทุกอย่างย้ายขึ้น cloud หมด ดูเหมือนจะดี: ทำงานได้จากทุกเครื่อง sync อัตโนมัติ ไม่ต้องห่วง backup

แต่พอใช้ไปนานๆ คนเริ่มเห็นด้านมืด:

• Wi-Fi ไม่ดี = แอปทำงานไม่ได้ (loading spinner หมุนตลอด)
• บริษัทเจ้าของแอปปิดตัว = ข้อมูลคุณหายไปด้วย (Google Reader, Google+, Wunderlist เคยเกิดมาแล้ว)
• ค่ารายเดือนเพิ่มทุกปี
• ข้อมูลส่วนตัวอยู่บน server คนอื่น = leak ได้ รัฐบาลเรียกตรวจได้ AI เอาไปเทรนได้

Local-first คือการ pushback ว่า — “เดี๋ยวก่อน ข้อมูลของฉัน ทำไมต้องอยู่บน serverของคนอื่น?”

7 หลักการของ local-first (สรุปสั้นๆ):

1. No spinners — UI ไม่ต้องรอ network — กดปุ่ม = เห็นผลทันที ไม่ต้องรอ server ตอบกลับ เพราะ data อยู่ในเครื่องคุณแล้ว

2. Your work is not trapped on one device — ข้อมูลเดียวกันใช้ได้บนทุกเครื่องของคุณ แต่ไม่ใช่เพราะ “อยู่ใน cloud” — เพราะ sync ระหว่างเครื่องของคุณเอง

3. Network optional — ทำงานได้เต็มที่ตอน offline ออนไลน์เป็นแค่ enhancement ไม่ใช่เงื่อนไข

4. Seamless collaboration — ทำงานพร้อมกันหลายคนได้ แม้บางคน offline merge เข้ากันเองได้เมื่อทุกคนกลับมาออนไลน์

5. The Long Now — ข้อมูลที่อยู่ได้ 100 ปี — ไฟล์ในเครื่องคุณเปิดได้เสมอ ไม่ขึ้นอยู่กับว่าบริษัทไหนยังอยู่ หรือ format ไหนยัง support

6. Privacy by default — ข้อมูลที่ไม่ต้องส่งไป server = ไม่มีใครแอบดูได้ การ sync ใช้ end-to-end encryption — server เห็นแต่ข้อมูลที่อ่านไม่ออก

7. You retain ultimate ownership — คุณมี copy ของข้อมูลทุกอันเสมอ ไม่ใช่แค่ “view” ของข้อมูลที่บริษัทเก็บไว้

สังเกตว่า — 7 ข้อนี้ ไม่ใช่เรื่องเทคนิค มันเป็นเรื่อง ความสัมพันธ์ระหว่างคุณกับ software ที่คุณใช้ จาก “เช่าใช้ของบริษัท” → “ของของคุณเอง”

มุมผู้บริหาร: ถ้า product เป็น productivity tool ที่ผู้ใช้ลงทุนเวลาเก็บข้อมูลส่วนตัว/งานสำคัญ — local-first เป็น differentiator ใหญ่กว่าฟีเจอร์ใดๆ คนยอมจ่ายแพงกว่าเพื่อ “ของฉัน อยู่กับฉัน”

CRDT — เทคนิคที่ทำให้ sync แบบไม่ขัดแย้งเป็นไปได้#

ฟังหลักการ local-first แล้วอาจเอ๊ะ — “ถ้า 2 คนแก้เอกสารเดียวกันตอน offline ทั้งคู่ พอ online ตอนเดียวกัน — ใครชนะ?”

คำตอบของยุคก่อนคือ — conflict ขึ้น modal “Version conflict — choose: keep mine / keep theirs / merge manually” ใครเคยใช้ Dropbox ปี 2010s น่าจะคุ้น

คำตอบของยุค local-first คือ — CRDT (Conflict-free Replicated Data Type)

CRDT เป็น โครงสร้างข้อมูลแบบใหม่ ที่ออกแบบมาเพื่อ merge ได้เอง 100% โดยไม่ต้องถามผู้ใช้ ไม่ว่ากี่คนแก้ ไม่ว่าแก้ตอนไหน ผลลัพธ์สุดท้ายเหมือนกันเสมอเมื่อทุกคน sync ครบ

อุปมาง่ายๆ — ลอง 2 คนที่อยู่ห้องคนละห้อง ต่างคนต่างมีกระดาษ shopping list ใบเดียวกัน

• คน A เพิ่ม “นม” + ลบ “ขนมปัง”
• คน B เพิ่ม “ไข่” + ลบ “ขนมปัง”

ตอนเดินมาเจอกัน ทั้งคู่มี list ต่างกัน — แต่ถ้าใช้ CRDT logic ผลลัพธ์ที่ถูกคือ list ที่มี “นม + ไข่” และ “ขนมปัง” หายไป (เพราะทั้งคู่เห็นพ้องว่าลบ) เป็นแบบนี้เสมอ ไม่ว่าใครเดินมาก่อน

ตัวอย่างที่คุณใช้อยู่ทุกวัน:

• Apple Notes — เปิดบน iPhone แก้ระหว่างเดินทาง พอ iPad เปิดที่บ้าน sync ทันที ถ้าคุณกับเพื่อนแก้คนละบรรทัดของ note เดียวกัน ทั้งสองส่วนรอดทั้งคู่
• Apple Reminders, Calendar — เหมือนกัน CRDT-based sync
• Linear — task management ของบริษัท startup ที่ engineer ทั่วโลกพูดถึง engineering team ของ Linear เขียน blog หลาย post อธิบายว่าออกแบบ sync engine แบบ CRDT ยังไง
• Figma — multi-cursor real-time design tool ที่ทุก designer ใช้ เบื้องหลังเป็น CRDT-like algorithm
• Automerge, Yjs — open-source CRDT libraries ที่ developer ใช้สร้าง local-first app

ส่วน Google Docs ใช้เทคนิคคนละแบบชื่อ Operational Transform (OT) คล้ายกันแต่ซับซ้อนกว่า และต้องมี central server ตัดสินใจ ต่างจาก CRDT ที่ทำงานแบบ peer-to-peer ได้

มุมผู้บริหาร: CRDT คือ enabling technology ที่ทำให้ “offline + collaborative” เกิดพร้อมกันได้ ก่อนหน้านี้ต้องเลือก — เอา offline (Dropbox style, conflict ง่าย) หรือเอา collaborative (Google Docs style, ต้อง online ตลอด) CRDT บอกว่า “เอาทั้งสองได้ครับ”

Cloudflare D1 — SQLite distributed บน edge#

พอ SQLite + local-first กลายเป็นที่นิยม cloud vendor ใหญ่ๆ เริ่มเข้ามาในตลาด

Cloudflare D1 คือบริการของ Cloudflare ที่ตอบโจทย์ — “อยากใช้ SQLite ที่ scale ได้ระดับโลก ทำยังไง”

แนวคิด D1 เรียบง่าย:

• ใช้ SQLite ตัวเดิม (ไม่ใช่ database engine ใหม่) — ecosystem, syntax, tooling เดิมหมด
• replicate ไฟล์ database ไปทั่ว edge network ของ Cloudflare 300+ เมือง
• การ อ่าน ทำได้จาก edge ที่ใกล้ user ที่สุด — latency ต่ำมาก (10-30ms)
• การ เขียน ส่งไปที่ primary region แล้ว replicate ไปที่อื่น — เขียนช้ากว่าอ่านเล็กน้อย

ผลคือ — ได้ database ที่ “ใกล้ user เสมอ” ในการอ่าน ซึ่งสำหรับเว็บส่วนใหญ่ที่ “อ่าน 99% เขียน 1%” = เหมาะมาก

ราคาด้วย — free tier ใจดีมาก 5GB storage + 25 ล้าน row read ต่อเดือน + 50,000 row write ต่อวัน เพียงพอสำหรับ side project, blog, small SaaS

ใช้คู่กับ Cloudflare Workers (function ที่รันบน edge) = full-stack app ที่รันทั่วโลกโดยไม่ต้องมี server เลย จ่ายตามที่ใช้ ไม่มี idle cost

Turso, LiteFS — SQLite ที่ replicate ระดับ edge#

Cloudflare ไม่ใช่เจ้าเดียวในตลาดนี้ ปี 2023-2024 มี vendor หลายเจ้าเข้ามาแข่ง:

Turso — startup ที่ fork SQLite ออกมาเป็น libSQL เพิ่ม feature ที่ SQLite ดั้งเดิมไม่มี เช่น embedded server mode (มี SQLite รันใกล้ๆ app เป็น sidecar), replication built-in, vector search. Turso มี free tier ใจดีคล้ายๆ D1 และเน้นกลุ่ม developer ที่อยาก deploy SQLite ระดับ global โดยไม่ต้องเขียน infrastructure เอง

LiteFS — open-source project ของ Fly.io ใช้ FUSE filesystem layer ดักจับการเขียนไฟล์ SQLite แล้ว replicate ไปยัง replica ทั่วโลก ข้อดีคือ — ไม่ต้องแก้ code app เลย app ยังเขียน SQLite แบบเดิม LiteFS ทำหน้า replication ให้ใต้ฝา

rqlite, dqlite — distributed SQLite อีก 2 ตัวที่อยู่ในวงการมานานกว่า เน้น HA (high availability) มากกว่า edge replication

ที่น่าสังเกตคือ — ทำไมทุก vendor edge cloud (Cloudflare, Fly.io, Turso, Vercel เริ่มเข้าตลาดด้วย Vercel Postgres for Edge) วิ่งเข้าหา SQLite พร้อมกัน?

คำตอบสั้นๆ — architecture ของ edge ต้องการ database ที่ embedded เพราะ Postgres/MySQL แบบ traditional มี connection pool, TCP handshake, authentication overhead ที่ “เปิด connection ใหม่ทุก request” ไม่ practical แต่ SQLite = open file ก็ใช้ได้ เหมาะกับ serverless/edge ที่ทุก function เปิด-ปิดเร็วๆ

เคสที่เหมาะกับ local-first#

ทีนี้มาดูว่า pattern นี้เหมาะกับ product แบบไหน:

1. Note-taking apps — คนใช้รายวัน, ต้องเปิดเร็ว, ต้องมีแม้ตอน offline

• Notion — sync engine ใหม่ (2021+) เป็น local-first
• Obsidian — markdown file บนเครื่องคุณ + sync เป็น add-on
• Apple Notes, Bear, Things — local-first by default

2. Task / project management

• Linear — sync engine ดังในวงการ engineer มี blog post เล่ารายละเอียดเทคนิค
• Things, OmniFocus — local-first ตั้งแต่แรก

3. Journal / Diary

• Day One — บันทึกส่วนตัวที่คนไม่อยากให้อยู่บน server ของคนอื่น

4. Expense tracker / Personal finance

• Copilot, MoneyMoney — ข้อมูลการเงินที่ sensitive เก็บใน local เท่านั้น sync ผ่าน iCloud/Dropbox ที่ encrypt แล้ว

5. Code editor

• VS Code — code อยู่ในเครื่องคุณ settings sync ขึ้น cloud (เป็น metadata เล็กๆ ไม่ใช่ data หลัก)

6. Mobile-first product

• ทุกอย่างที่ “user คาดหวังว่าเปิดบนรถไฟใต้ดินที่ไม่มีสัญญาณก็ต้องใช้ได้”

Pattern ที่เห็นในเคสเหล่านี้คือ — data เป็นของ user, ไม่ต้อง share กับคนอื่นเป็นหลัก, scenario offline เกิดขึ้นจริง

เคสที่ “ไม่เหมาะ” — ยังต้องมี central database#

แต่อย่าเพิ่งคิดว่า local-first คือคำตอบของทุกอย่างนะ มีหลายเคสที่ central database ยังจำเป็นมาก:

1. Banking / Fintech — เงินในบัญชีคุณ ต้อง มี single source of truth บน server ของธนาคาร ห้ามมีหลาย version ที่ต้อง merge เพราะถ้า merge ผิด = เงินหาย/เพิ่มผิด เคส EP.08 ที่เคยคุยเรื่อง transaction integrity ก็ตรงนี้แหละ

2. Multi-tenant SaaS ที่มี admin view — ถ้า admin ต้องเห็นข้อมูลของ user 10,000 คนพร้อมกัน data จะอยู่บนเครื่อง admin ไม่ practical ต้องมี central DB ให้ admin query

3. Social network / Feed — feed Twitter/Facebook ที่ต้องเห็นโพสต์จากคนทั่วโลกแบบ real-time จะให้ทุกคนเก็บ copy ของ feed ทั้งโลกในเครื่อง = ทำไม่ได้

4. E-commerce — inventory + order — สต็อกสินค้าต้อง consistent ระหว่างหลาย channel (เว็บ + LINE + ร้านหน้าร้าน) ถ้าขายของชิ้นเดียวกันให้ลูกค้า 2 คนพร้อมกันเพราะ stock ไม่ sync = ปัญหาใหญ่

5. Real-time multiplayer game — game state ต้องอยู่ที่ server กลาง ป้องกัน cheat และ sync ระหว่างผู้เล่น

เส้นแบ่งคล้ายๆ EP.09 — ถ้า data เป็น “ของ user” → local-first เวิร์ก. ถ้า data เป็น “ของระบบ” หรือ “shared resource” → ต้องมี central

มุมผู้บริหาร — ทำไม mobile-first product 2026 ต้องคิด local-first ตั้งแต่ day 1#

ถ้ากำลังจะสร้าง product ใหม่ที่เป็น mobile app หรือ desktop app ที่ user ใช้ส่วนตัว — ผมอยากชวนให้พิจารณา local-first ตั้งแต่วันแรก ด้วยเหตุผล 4 ข้อ:

1. Cost — ลด server cost มหาศาล — server ไม่ต้องรับ traffic ทุก action ของ user (ทุกการพิมพ์ ทุกการ tap) รับเฉพาะตอน sync เท่านั้น ราคาต่อ user ลดเป็น order of magnitude

2. UX — ไม่มี loading spinner = better experience — UI ตอบสนองทันทีทุกครั้ง ไม่มี “เน็ตช้า แอปก็ช้า” ที่ลูกค้าโทษคุณ ทั้งที่จริงเป็นเน็ตของเขาเอง

3. Privacy + trust — ข้อมูลที่ไม่อยู่บน server ของคุณ = leak ไม่ได้ ผู้ใช้ที่กังวลเรื่อง privacy (กลุ่มที่โตเร็วทุกปี) จะ trust product ที่ “ของฉัน อยู่กับฉัน” มากกว่า

4. Compliance ง่ายขึ้น (PDPA / GDPR / data residency) — กฎหมายความเป็นส่วนตัวทั่วโลกซับซ้อนขึ้นทุกปี local-first ลดภาระตรงนี้เพราะ “data ที่ไม่เก็บ = ไม่ต้อง comply”

ที่สำคัญคือ — local-first ไม่ได้แปลว่าไม่มี cloud แปลว่า cloud เป็น sync layer ไม่ใช่ source of truth ผู้ใช้ยังได้ประโยชน์ของ cloud (sync ข้ามเครื่อง, backup, collaboration) แค่ไม่ใช่ “เช่าข้อมูลตัวเองจากเรา”

product ที่ออกแบบ local-first ตั้งแต่ day 1 ทำได้ง่าย product ที่จะ retrofit local-first เข้าไปทีหลัง = rewrite เกือบทั้ง app เพราะ assumption เรื่อง “data อยู่บน server” มันแทรกอยู่ทุกที่

ปิดท้าย — เว็บ → app → SaaS เริ่มเป็นภาพชัดขึ้น#

ถึงตรงนี้ลองวาง 2 ตอนไว้ข้างกัน

EP.09 พูดเรื่อง เว็บที่ไม่มี database — content site เสิร์ฟจาก edge ทั่วโลก ทุกอย่าง pre-built ไม่ต้องมี server กลาง

EP.10 พูดเรื่อง app ที่ database อยู่บนเครื่อง user — Notion, Linear, Obsidian, Apple Notes ที่ทำงานได้ตอน offline แล้ว sync ตอนมีเน็ต

ทั้ง 2 มาจาก idea เดียวกัน — เลิกพึ่ง database server กลางเป็นจุดเดียว กระจายออกไป บางทีไป edge บางทีไปเครื่อง user

แต่ทั้ง 2 pattern เหมาะกับ product ขนาดเล็ก-กลาง ที่ user ทำงานคนเดียวเป็นหลัก ถ้า product โตขึ้น มี user เป็น 10,000 คน ใช้พร้อมกัน มีทีม admin ที่ต้อง query ข้อมูลข้าม user มี analytics dashboard ที่ต้องอัปเดตทุกวินาที — ตอนนั้นต้องการ database แบบไหน?

EP.11 จะคุยเรื่อง — Serverless DB Stack สำหรับ startup — เครื่องมืออะไรที่ทำให้ทีม engineer 3 คน รัน SaaS ที่มี user เป็นหมื่นได้โดยไม่ต้องจ้าง DBA Neon, PlanetScale, Supabase, Cloudflare D1, Turso — vendor พวกนี้แข่งกันยังไง เลือกตัวไหนดีในสถานการณ์ไหน

→ EP.11 — มุม Startup: Serverless DB Stack