ถ้าเว็บของคุณต้องมี login และเก็บข้อมูลแยกรายคน ให้เลือก Supabase หรือ Firebase อย่างใดอย่างหนึ่ง ถ้าเป็นเครื่องมือใช้กันภายในทีมและอยากให้คนในทีมเปิดดูข้อมูลได้เอง Google Sheets คู่กับ Google Apps Script ก็เพียงพอ ส่วนเครื่องมือที่แค่รับไฟล์มาคำนวณแล้วแสดงผล ไม่ต้องมี database เลยก็ได้ ให้ทุกอย่างทำงานใน browser ไปเลย
คำถามนี้เป็นด่านแรกที่คนสร้างเว็บด้วย AI มักติด เพราะ Claude Code, Codex หรือ Cursor เขียนหน้าเว็บให้เสร็จได้เร็วมาก แต่พอถึงจังหวะที่ต้องเก็บข้อมูลจริง ถ้าเราไม่ได้บอกว่าจะเก็บที่ไหน AI มักเลือกให้เองตามความเคยชิน ซึ่งอาจไม่ตรงกับงานของเรา บทความนี้พาไล่ทีละทางเลือก พร้อมตัวอย่างผลงานจริงจากทำเนียบแอปเทพที่ตอนนี้มีผลงาน 2393 รายการ
ตอบ 4 คำถามนี้ก่อนเลือก database
ก่อนเปิดเทียบ feature ของแต่ละเจ้า ลองตอบคำถามเหล่านี้ให้ได้ก่อน เพราะคำตอบจะตัดตัวเลือกออกไปเองเกินครึ่ง
- ข้อมูลต้องตามผู้ใช้ไปทุกเครื่องไหม ถ้าเปิดจากมือถือแล้วต้องเห็นข้อมูลเดียวกับที่บันทึกไว้ในเครื่องที่ทำงาน แปลว่าต้องมี database กลาง
- ต้องแยกข้อมูลของแต่ละคนไหม ถ้าใช่ ต้องมีระบบ login และกฎกำหนดสิทธิ์ว่าใครเห็นข้อมูลของใคร
- มีหลายคนแก้ข้อมูลชุดเดียวกันพร้อมกันไหม เช่น เพื่อนช่วยกันจดแผนเที่ยว หรือพนักงานหลายคนบันทึก stock
- ใครเป็นคนดูแลข้อมูลหลังเปิดใช้งาน ถ้าเป็นเจ้าของร้านหรือฝ่ายบัญชีที่ไม่เขียนโค้ด การเปิดข้อมูลดูใน spreadsheet ได้เลยมีค่ามาก
ถ้าคำตอบของข้อ 1 ถึง 3 คือไม่ทั้งหมด คุณอาจไม่ต้องมี database ด้วยซ้ำ
ตารางเทียบ 4 ทางเลือกหลัก
| ทางเลือก | เหมาะกับงานแบบไหน | จุดแข็ง | ข้อควรระวัง |
|---|---|---|---|
| ไม่มี database ประมวลผลใน browser | เครื่องคำนวณ ตัวแปลงไฟล์ dashboard จากไฟล์ที่ผู้ใช้เลือกเอง | ไม่มีค่า server ข้อมูลไม่ออกจากเครื่องผู้ใช้ deploy บน static hosting ได้ทันที | ข้อมูลไม่ตามไปเครื่องอื่น ล้างข้อมูล browser แล้วสิ่งที่เก็บไว้หายไปด้วย |
| Google Sheets คู่กับ Google Apps Script | เครื่องมือภายในร้านหรือทีมขนาดเล็ก | คนที่ไม่เขียนโค้ดเปิดดูและแก้ข้อมูลได้ เริ่มได้โดยไม่ต้องสมัครบริการใหม่ | ช้าลงเมื่อข้อมูลเยอะ มี quota การเรียกใช้ ไม่เหมาะกับเว็บสาธารณะที่คนเข้าพร้อมกันมาก |
| Supabase | เว็บแอปที่มี login และข้อมูลเชื่อมโยงกันหลาย table | เป็น Postgres ใช้ SQL ได้เต็มรูปแบบ มี Auth และ Storage ในตัว | ต้องเปิด Row Level Security ให้ครบทุก table ไม่เช่นนั้นข้อมูลอาจถูกอ่านจากภายนอกได้ |
| Firebase | แอปที่ข้อมูลต้อง update แบบ realtime และงานที่หลายคนใช้พร้อมกัน | Firestore sync ข้อมูลให้ทุกเครื่อง มี Auth และ Hosting ในชุดเดียว | คิดค่าใช้จ่ายตามจำนวนครั้งที่อ่านและเขียน ออกแบบ query ไม่ดีค่าใช้จ่ายขึ้นเร็ว |
ทางเลือกที่ 1 ไม่ต้องมี database เลย
หลายคนเข้าใจว่าเว็บแอปทุกตัวต้องมี database แต่งานหลายประเภทไม่จำเป็น โดยเฉพาะงานที่รับข้อมูลเข้า ประมวลผล แล้วแสดงผลจบในครั้งเดียว
ตัวอย่างที่ชัดคือ Monthly Sales Forecast Assistant ซึ่งอ่านข้อมูลขายสด ขายเชื่อ และใบรับเงินมัดจำจาก Express จำนวน 3 ไฟล์ แล้วสรุปยอดขายพร้อมพยากรณ์ความต้องการเดือนถัดไปสำหรับผู้ผลิตหลังคาโลหะและฉนวน PU ผลงานนี้แสดงสินค้าขายดี ระยะเวลาที่สินค้าคงคลังรองรับการขายได้ และรายงานแยกตามทีมและลูกค้า จุดที่น่าสนใจคือข้อมูลของผลงานระบุว่าประมวลผลใน browser โดยไม่ส่งข้อมูลขึ้น server วิธีนี้เข้ากับงานที่แตะข้อมูลยอดขายและลูกค้าของบริษัท เพราะตัดความกังวลเรื่องข้อมูลรั่วไปได้ตั้งแต่ต้น ผลงานนี้ host อยู่บน GitHub Pages
ถ้าอยากให้แอปจำค่าบางอย่างไว้ เช่น การตั้งค่า หรือรายการที่ทำล่าสุด ใช้ localStorage หรือ IndexedDB ของ browser ได้ แต่ต้องบอกผู้ใช้ให้ชัดว่าข้อมูลอยู่ในเครื่องนี้เท่านั้น และควรมีปุ่ม export ออกเป็นไฟล์ไว้สำรองเสมอ
เวลาสั่ง AI ให้พูดตรง ๆ ว่าต้องการเว็บแบบ static ที่ประมวลผลทุกอย่างฝั่ง browser ห้ามส่งข้อมูลออกไปที่ server ใด ๆ ถ้าไม่บอก AI อาจสร้าง backend มาให้โดยที่เราไม่ได้ต้องการ
ทางเลือกที่ 2 Google Sheets คู่กับ Google Apps Script
ทางเลือกนี้ถูกมองข้ามบ่อยเพราะดูไม่เป็นมืออาชีพ แต่สำหรับเครื่องมือภายในองค์กรกลับเป็นคำตอบที่ลงตัว เหตุผลหลักคือคนที่ไม่เขียนโค้ดเปิด sheet ดูข้อมูลดิบ แก้รายการที่ผิด หรือทำสรุปต่อเองได้โดยไม่ต้องรอคนสร้างแอป
BCF Vault เป็นตัวอย่างที่ดี ผลงานนี้ติดตามสินค้า LOT และวันหมดอายุในห้องเย็น 4 ห้อง รวม 178 ช่องเก็บของ พนักงาน Black Chicken Farm ใช้ค้นหาตำแหน่งสินค้า บันทึกรับเข้าและเบิกออก ออกใบเสร็จ และดูรายงานได้ ข้อมูลในทำเนียบระบุ backend เป็น Google Sheets, LINE LIFF และ Google Apps Script ส่วนหน้าเว็บ host บน GitHub Pages งานลักษณะนี้มีผู้ใช้เป็นพนักงานกลุ่มเดียว ขอบเขตข้อมูลชัดเจน จึงไม่จำเป็นต้องใช้ database ขนาดใหญ่
ข้อจำกัดที่ต้องรู้ก่อนเลือกทางนี้มี 3 เรื่อง
- ความเร็ว การอ่านและเขียนผ่าน Google Apps Script ช้ากว่า database จริงอย่างรู้สึกได้ ยิ่งจำนวน row มากยิ่งช้า
- quota Google กำหนดเพดานการเรียกใช้และเวลาทำงานของ script ไว้ ถ้าคนใช้พร้อมกันจำนวนมากจะชนเพดานได้
- การเขียนพร้อมกัน ถ้า 2 คนบันทึกในจังหวะเดียวกัน ข้อมูลอาจทับกัน ควรสั่ง AI ให้ใช้ LockService ใน script ที่เขียนข้อมูล
ถ้าวันหนึ่งงานโตจนเริ่มช้า ค่อยย้ายไป Supabase หรือ Firebase ได้ ข้อมูลใน sheet export ออกเป็น CSV แล้ว import เข้าระบบใหม่ได้ไม่ยาก
ทางเลือกที่ 3 Supabase
Supabase คือ Postgres ที่มาพร้อม Auth, Storage และ API ให้หน้าเว็บเรียกใช้ได้โดยตรง เหมาะกับข้อมูลที่เชื่อมโยงกัน เช่น ลูกค้า 1 คนมีหลาย order และแต่ละ order มีหลายรายการสินค้า
ตัวอย่างจากทำเนียบคือ Perfume Lab เครื่องมือสำหรับนักปรุงน้ำหอมที่เก็บรายชื่อสารใน stock คำนวณและจดสูตร รวมถึงคำนวณเวลาขึ้น final product นักปรุงสร้าง Base แล้ว import ไปใช้ในสูตรได้ และแยกข้อมูลของแต่ละบัญชีด้วย login ข้อมูลในทำเนียบระบุ backend เป็น Supabase และ host เป็น GitHub Pages ข้อมูลประเภทวัตถุดิบ สูตร และ Base ที่อ้างถึงกันไปมาแบบนี้ เป็นโจทย์ที่ database แบบ relational ตอบได้ตรงจุด
เหตุผลที่ Supabase เข้ากับการทำงานร่วมกับ AI ได้ดีมี 2 ข้อ ข้อแรก SQL เป็นภาษาที่ AI เขียนได้แม่น ข้อสอง โครงสร้าง table เก็บเป็นไฟล์ migration ใน project ได้ AI จึงอ่านโครงสร้างทั้งหมดได้ก่อนเขียนโค้ด ไม่ต้องเดา
สิ่งที่ต้องระวังที่สุดคือ Row Level Security หรือ RLS เพราะหน้าเว็บคุยกับ database โดยตรง ถ้า table ไหนไม่ได้เปิด RLS และไม่ได้เขียน policy กำกับ คนนอกอาจอ่านข้อมูลใน table นั้นได้ นอกจากนี้ควรอ่านเงื่อนไขของ plan ฟรีให้ดี เพราะ project ที่ไม่มีการใช้งานต่อเนื่องช่วงหนึ่งอาจถูกพักไว้
ทางเลือกที่ 4 Firebase
Firebase เป็นชุดบริการของ Google ที่มี Firestore เป็น database แบบ NoSQL เก็บข้อมูลเป็น document และ collection จุดเด่นคือการ sync ข้อมูลแบบ realtime เมื่อคนหนึ่งแก้ข้อมูล อีกคนเห็นการเปลี่ยนแปลงโดยไม่ต้อง refresh หน้า และมี Auth กับ Hosting ให้ใช้ในที่เดียว
ในทำเนียบมีผลงานที่ระบุ backend เป็น Firebase อยู่หลายชิ้น เช่น Triptactoe ที่รวมการวางแผนเที่ยวไว้ในที่เดียวเพื่อลดการสลับดูหลาย app ผู้ใช้แชร์แผนกับเพื่อนและช่วยกันจดข้อมูลได้ อีกชิ้นคือ CourtBuddy ที่ช่วยค้นหากลุ่มผู้เล่น tennis และ pickleball สำหรับคนที่อยากหาเพื่อนร่วมเล่นกีฬา งานที่มีคนหลายคนเข้ามาใช้ข้อมูลชุดเดียวกันแบบนี้ เป็นโจทย์ประเภทที่ Firestore ถูกออกแบบมารองรับ
ข้อควรระวังของ Firebase มี 2 เรื่อง เรื่องแรกคือค่าใช้จ่าย Firestore นับตามจำนวน document ที่อ่านและเขียน หน้าที่ดึงข้อมูลทั้ง collection ทุกครั้งที่เปิดจะกินโควตาเร็วมาก เรื่องที่สองคือ security rules ตอนสร้าง project ใหม่ หลายคนเลือกโหมดทดสอบที่เปิดให้ทุกคนอ่านเขียนได้ แล้วลืมกลับมาปิด ต้องเขียน rules ให้เรียบร้อยก่อนเปิดใช้จริง
Supabase หรือ Firebase ตัดสินใจยังไง
ถ้ายังเลือกไม่ได้ ให้ดูที่ลักษณะข้อมูลเป็นหลัก
- ข้อมูลเป็นตาราง มีความสัมพันธ์กัน ต้องทำรายงานหรือรวมยอดบ่อย เลือก Supabase เพราะ SQL ทำเรื่องนี้ได้ง่ายกว่ามาก
- ข้อมูลเป็นก้อนอิสระต่อกัน เช่น โพสต์ ข้อความ หรือบันทึกรายชิ้น และต้องเห็นการเปลี่ยนแปลงทันที เลือก Firebase
- ทำแอปมือถือเป็นหลัก หรือใช้บริการอื่นของ Google อยู่แล้ว Firebase จะต่อกันได้ลื่นกว่า
- อยากย้ายออกได้ง่ายในอนาคต Supabase ได้เปรียบ เพราะเป็น Postgres มาตรฐาน export ไปใช้ที่อื่นได้
ทั้ง 2 เจ้ามี plan ฟรีให้เริ่มต้น แต่เงื่อนไขเปลี่ยนได้ ควรตรวจสอบที่หน้าเว็บทางการก่อนตัดสินใจทุกครั้ง
ข้อผิดพลาดเรื่อง database ที่ควรกันไว้ตั้งแต่วันแรก
วาง key ลับไว้ในหน้าเว็บ
Supabase มี key 2 แบบ แบบสาธารณะใช้ในหน้าเว็บได้เพราะถูกคุมด้วย RLS ส่วน service role key ข้าม RLS ได้ทั้งหมด ห้ามอยู่ในโค้ดฝั่ง browser เด็ดขาด ฝั่ง Firebase นั้น config ที่อยู่ในหน้าเว็บไม่ใช่ความลับ ความปลอดภัยทั้งหมดจึงขึ้นกับ security rules ให้สั่ง AI ตรวจโค้ดหา key ที่หลุดก่อน deploy ทุกครั้ง
ไม่มี backup
ก่อนให้ AI แก้โครงสร้าง table หรือรันคำสั่งลบข้อมูล ให้ export ข้อมูลเก็บไว้ก่อนเสมอ AI ทำงานเร็ว ซึ่งหมายความว่าลบข้อมูลผิดได้เร็วเช่นกัน
ทดสอบกับข้อมูลจริง
แยก project สำหรับทดลองกับ project ที่ผู้ใช้จริงใช้อยู่ออกจากกัน แล้วให้ AI ทำงานกับตัวทดลองเท่านั้น
เปลี่ยนโครงสร้างไปเรื่อย ๆ โดยไม่จด
ให้ AI เขียนไฟล์สรุปโครงสร้างข้อมูลเก็บไว้ใน project และ update ทุกครั้งที่มีการเปลี่ยน เมื่อเปิดงานรอบใหม่ AI จะอ่านไฟล์นี้แล้วทำงานต่อได้ถูกต้อง
ตัวอย่าง prompt สั่ง AI วางโครง database
แทนที่จะพิมพ์สั้น ๆ ว่าช่วยทำระบบเก็บข้อมูลให้หน่อย ลองให้ข้อมูลครบแบบนี้
ฉันกำลังทำเว็บแอปบันทึก stock สำหรับร้านขนาดเล็ก มีพนักงานใช้งานพร้อมกันไม่เกิน 5 คน ต้องมี login แยกสิทธิ์เจ้าของร้านกับพนักงาน ข้อมูลหลักคือสินค้า การรับเข้า และการเบิกออก ช่วยเสนอโครงสร้าง table พร้อมเหตุผล เขียน policy กำหนดสิทธิ์ให้ครบทุก table แล้วอธิบายว่าถ้าข้อมูลโตขึ้น 10 เท่าจะมีจุดไหนต้องปรับ ยังไม่ต้องเขียนโค้ดหน้าเว็บ
prompt แบบนี้บังคับให้ AI คิดเรื่องสิทธิ์และการเติบโตของข้อมูลตั้งแต่ต้น ได้ผลดีกว่าปล่อยให้สร้างไปแก้ไปมาก
สรุป เริ่มจากทางที่เล็กที่สุดที่ตอบโจทย์
หลักคิดง่าย ๆ คือเลือกทางที่เล็กที่สุดที่ยังทำงานได้ครบ เครื่องมือวิเคราะห์ไฟล์ไม่ต้องมี database เครื่องมือภายในทีมเริ่มที่ Google Sheets ได้ เว็บแอปที่มีผู้ใช้หลายคนและต้อง login ค่อยไป Supabase หรือ Firebase ตามลักษณะข้อมูล การเริ่มเล็กทำให้เปิดใช้งานได้เร็ว และได้เห็นว่าคนใช้จริงต้องการอะไรก่อนลงแรงกับระบบใหญ่
ถ้าอยากเห็นว่าคนไทยคนอื่นเลือกแบบไหน เข้าไปดูผลงานในทำเนียบแอปเทพได้ หลายชิ้นมีข้อมูล host และ backend กำกับไว้ ใช้เป็นแนวทางตัดสินใจสำหรับงานของคุณเองได้เลย
