Supabase หรือ Firebase: งานอ่านกับงานเขียนให้คำตอบคนละแบบ

ถ้าข้อมูลหลายชุดต้องเชื่อมกันเพื่อทำธุรกรรมหรือสร้างผลลัพธ์ด้วย SQL ให้เริ่มพิจารณา Supabase ซึ่งใช้ PostgreSQL หากแอปดึงเอกสารตามรูปแบบหน้าจอที่ออกแบบไว้และต้องติดตามการเปลี่ยนแปลง Cloud Firestore ใน Firebase เป็นอีกทางเลือกที่เหมาะกับการประเมิน แต่คำว่าอ่านหนักหรือเขียนหนักยังบอกไม่ได้ว่าระบบใดถูกกว่า เพราะ Supabase คิดค่าเครื่องฐานข้อมูลตามเวลาที่ใช้ ส่วน Firestore แบบ Standard คิดการอ่านและเขียนตามเอกสารที่เกี่ยวข้อง

การเปรียบเทียบนี้เจาะจง Cloud Firestore ไม่ได้เหมารวมบริการฐานข้อมูลทุกชนิดใน Firebase หนึ่งหน้าจอที่แสดงผลเหมือนกันอาจใช้คำสั่ง SQL เพื่อประกอบข้อมูลจากหลายตาราง หรืออ่านเอกสารหลายชิ้นจากคอลเลกชันก็ได้ แบบจำลองข้อมูลของ Cloud Firestore จัดเก็บเอกสารภายในคอลเลกชัน แทนตารางและแถวแบบ SQL จำนวนเอกสารที่ต้องเปิดอ่านและปริมาณข้อมูลที่เก็บซ้ำจึงเป็นส่วนหนึ่งของการเลือกสถาปัตยกรรมตั้งแต่ต้น

รูปข้อมูลกำหนดงานที่ฐานข้อมูลต้องทำ

ในระบบคำสั่งซื้อ ข้อมูลลูกค้า สินค้า คำสั่งซื้อ และรายการชำระเงินมักมีความสัมพันธ์กัน PostgreSQL เปิดทางให้เก็บข้อมูลแต่ละประเภทในตารางที่เชื่อมกัน แล้วใช้ SQL เลือกเฉพาะแถวและคอลัมน์ที่หน้าจอหรือรายงานต้องการ วิธีนี้มีประโยชน์เมื่อคำถามทางธุรกิจเปลี่ยนบ่อย เช่น ต้องรวมยอดตามสินค้าและช่วงเวลา หรือหาคำสั่งซื้อที่มีเงื่อนไขจากหลายตาราง ทีมยังต้องออกแบบดัชนีและตรวจแผนการทำงานของคำสั่งที่ใช้บ่อย เพราะ SQL ที่ยืดหยุ่นไม่ได้ทำให้การอ่านทุกแบบเร็วเท่ากัน

Firestore เริ่มจากเอกสารที่แอปจะอ่านจริง หากหน้ารายละเอียดคำสั่งซื้อต้องแสดงข้อมูลเพียงชุดที่กำหนดไว้ การจัดข้อมูลให้อยู่ในเอกสารที่เข้าถึงได้ตรงทางช่วยให้การอ่านเรียบง่าย เอกสารหนึ่งชิ้นอาจมีข้อมูลซ้อนอยู่ภายในหรือเชื่อมไปยังเอกสารอื่น แต่ถ้าหน้าจอต้องดึงข้อมูลจากหลายคอลเลกชัน แอปอาจต้องอ่านหลายชิ้นเพื่อประกอบผลลัพธ์เดียวกัน จำนวนคำขอจากผู้ใช้จึงไม่เท่ากับจำนวนการอ่านเอกสารที่นำไปคิดเงิน

ตัวอย่างสมมติคือร้านค้าที่เก็บชื่อสินค้าไว้ทั้งในเอกสารสินค้าและในเอกสารคำสั่งซื้อ การฝังชื่อสินค้าในคำสั่งซื้อช่วยให้แสดงประวัติรายการได้โดยไม่ต้องอ่านเอกสารสินค้าเพิ่ม แต่ทีมต้องตัดสินใจว่าชื่อในคำสั่งซื้อควรคงตามวันที่ซื้อ หรือเปลี่ยนตามชื่อสินค้าปัจจุบัน หากต้องแก้สำเนาทุกแห่ง งานเขียนและกฎการรักษาความสอดคล้องของข้อมูลจะเพิ่มขึ้น ทางเลือกนี้ส่งผลทั้งต่อค่าใช้จ่ายและความหมายของข้อมูลที่ผู้ใช้เห็น

จุดแยกจึงอยู่ที่คำถามหลักของผลิตภัณฑ์ ถ้าความสัมพันธ์ การรวมข้อมูล และรายงานที่ยังเปลี่ยนรูปเป็นงานประจำ PostgreSQL ให้เครื่องมือที่ตรงกว่า ถ้าหน้าจอส่วนใหญ่ขอเอกสารตามรหัสหรือคำค้นที่รู้รูปแบบล่วงหน้า Firestore อาจลดงานประกอบข้อมูลในฝั่งแอปได้ ทั้งสองกรณีต้องเทียบจากผลลัพธ์เดียวกัน ไม่ใช่จับจำนวนคำขอ API ของระบบหนึ่งไปเทียบกับจำนวนเอกสารของอีกระบบ

ค่าใช้จ่ายเพิ่มขึ้นคนละจุด

สำหรับ Supabase รายละเอียดการคิดเงินของแพลตฟอร์ม ระบุว่าแต่ละโครงการมี Postgres instance ของตน และคิดค่า compute แยกจากปริมาณการใช้ฐานข้อมูล; โควตาแผน Pro รวมการส่งข้อมูลออก 250 GB และผู้ใช้ที่ใช้งานรายเดือน 100,000 รายก่อนคิดส่วนเกิน โควตาการใช้งานเหล่านี้นับในระดับองค์กร ขณะที่การเพิ่มโครงการทำให้มีค่า compute ของ instance เพิ่ม คำว่าไม่เก็บเงินต่อการอ่านแต่ละแถวจึงไม่ได้แปลว่าการอ่านจำนวนมากไม่มีต้นทุน

เมื่อคำสั่ง SQL หนักขึ้นหรือมีคำขอพร้อมกันมากขึ้น เครื่องที่เลือกอาจต้องมีทรัพยากรมากกว่าเดิม ต้นทุน compute จึงผูกกับขนาด instance และเวลาที่ใช้งาน ขณะเดียวกันข้อมูลที่ส่งออก พื้นที่เก็บ และบริการอื่นที่แอปใช้มีเงื่อนไขของตนเอง สำหรับแอปที่มีผู้ใช้ไม่สม่ำเสมอ ควรมองทั้งช่วงเงียบและช่วงสูงสุด: ค่าเครื่องเกิดตลอดเวลาที่เปิดใช้งาน แต่ขนาดเครื่องที่พอในวันธรรมดาอาจไม่พอในช่วงที่ทุกคนอ่านหรือเขียนพร้อมกัน

ฝั่ง กติกาคิดเงินของ Cloud Firestore นับเอกสารที่อ่าน เขียน และลบ รวมถึงการอ่านรายการดัชนีสำหรับคำค้นบางแบบ พื้นที่จัดเก็บ และข้อมูลที่ส่งออก โดยฐานข้อมูลที่เข้าเกณฑ์หนึ่งชุดต่อโครงการมีโควตาฟรีการอ่าน 50,000 ครั้ง การเขียน 20,000 ครั้ง และการลบ 20,000 ครั้งต่อวัน การอ่านรายการดัชนีไม่ได้เกิดค่าใช้จ่ายแบบเดียวกันกับทุกคำค้น และการอ่านผ่าน listener อาจเกิดซ้ำเมื่อเอกสารในผลลัพธ์เปลี่ยนหรือเมื่อเชื่อมต่อใหม่ตามการตั้งค่าเก็บข้อมูลออฟไลน์ ราคาหลังโควตาขึ้นกับที่ตั้งฐานข้อมูล จึงต้องใช้อัตราของภูมิภาคและรุ่นบริการที่จะเปิดจริง

ต้นทุนของ Firestore จึงตอบสนองต่อรูปแบบการเรียกข้อมูลโดยตรง หน้าที่คืนเอกสารจำนวนมากทุกครั้งที่เปิดอาจใช้โควตาเร็ว แม้ตัวเอกสารจะเล็ก ขณะที่หน้าที่อ่านเอกสารไม่กี่ชิ้นเป็นครั้งคราวอาจมีค่าใช้จ่ายต่ำ ใน Supabase คำสั่งที่คืนแถวจำนวนมากไม่ถูกนับเป็นค่าอ่านรายแถว แต่ยังใช้ CPU หน่วยความจำ ดิสก์ และการส่งข้อมูลออก ความต่างนี้ทำให้การประหยัดของระบบหนึ่งในแอปอ่านหนักไม่ใช่คำตอบอัตโนมัติสำหรับแอปเขียนหนัก

เครื่องคำนวณโหลด: อ่าน เขียน และส่งการเปลี่ยนแปลง

เริ่มด้วยการนับงานหนึ่งวันจากพฤติกรรมของแอป ไม่ใช่จากจำนวนผู้ใช้ที่ลงทะเบียน แยกจำนวนครั้งที่เปิดแต่ละหน้าจอ จำนวนเอกสารที่คืนต่อครั้ง จำนวนรายการที่การกระทำหนึ่งครั้งสร้างหรือแก้ และจำนวนผู้รับการเปลี่ยนแปลง จากนั้นทำอีกชุดสำหรับวันที่มีการใช้งานสูง เพราะยอดรายเดือนเท่ากันอาจเกิดจากโหลดที่กระจายสม่ำเสมอหรือกระจุกในช่วงสั้น ซึ่งกระทบขนาด compute และเวลาตอบสนองต่างกัน

• แอปอ่านหนัก: สำหรับ Firestore ให้คูณจำนวนครั้งที่เปิดหน้าด้วยจำนวนเอกสารที่อ่านต่อครั้ง แล้วบวกการอ่านจากคำค้นอื่น การเปิด listener ครั้งแรก และการเชื่อมต่อใหม่ ตัวอย่างสมมติ หากหน้ารายการเปิด 10,000 ครั้งต่อวันและคืนครั้งละ 12 เอกสาร จะเกิดการอ่าน 120,000 ครั้งก่อนรวมงานอื่น สำหรับ Supabase ให้ใช้คำสั่ง SQL ที่คืนข้อมูลเท่ากัน แล้วประเมินขนาด instance ที่รองรับเวลาตอบสนองในช่วงใช้งานสูง พร้อมนับข้อมูลที่ส่งออก
• แอปเขียนหนัก: สำหรับ Firestore ให้นับเอกสารที่แต่ละเหตุการณ์สร้าง แก้ หรือลบ ไม่ใช่นับครั้งที่ผู้ใช้กดปุ่ม ตัวอย่างสมมติ หากมีคำสั่งซื้อ 4,000 รายการต่อวันและแต่ละรายการแก้เอกสาร 3 ชิ้น จะมีการเขียน 12,000 ครั้งก่อนรวมการปรับสำเนาข้อมูลหรือการเขียนจากกระบวนการเบื้องหลัง สำหรับ Supabase ให้ดูจำนวนแถวที่เปลี่ยน ดัชนีที่ต้องปรับ งานภายในธุรกรรม และความสามารถของเครื่องในช่วงที่การเขียนเกิดพร้อมกัน
• แอปเรียลไทม์: แยกจำนวนการเปลี่ยนข้อมูลออกจากจำนวนผู้รับ ตัวอย่างสมมติ หากเอกสารหนึ่งชุดเปลี่ยน 600 ครั้งและทุกครั้งเข้าถึงผู้ฟัง 80 ราย จะเกิดการส่งผลอัปเดต 48,000 ครั้งก่อนพิจารณาการอ่านครั้งแรกหรือการเชื่อมต่อใหม่ของ Firestore สำหรับ Supabase ให้ประเมินข้อความที่ส่งถึงผู้ฟังตามช่องทางที่ใช้จริง พร้อมข้อมูลขาออกและจำนวนการเชื่อมต่อพร้อมกัน

สูตรเปรียบเทียบรายเดือนควรแยกรายการให้เห็นชัด: ฝั่ง Supabase คือค่าบริการแผน บวกค่า compute ของทุก instance ตามเวลา บวกส่วนเกินของการส่งข้อมูล พื้นที่เก็บ และข้อความเรียลไทม์ที่เกี่ยวข้อง ฝั่ง Firestore คือค่าการอ่าน เขียน ลบ และงานดัชนีที่เข้าเกณฑ์หลังโควตา บวกพื้นที่เก็บและการส่งข้อมูลออก หากแอปใช้ระบบยืนยันตัวตนหรือเก็บไฟล์ด้วย ให้คิดส่วนนั้นแยกจากฐานข้อมูลก่อนรวมยอด มิฉะนั้นจะตอบไม่ได้ว่าค่าใช้จ่ายเพิ่มเพราะงานอ่านหรือเพราะบริการประกอบ

การคำนวณแบบนี้ยังเผยทางเลือกด้านการออกแบบ สมมติหน้ารายการคืนเอกสารมากกว่าที่ผู้ใช้เห็นจริง การจำกัดผลลัพธ์และแบ่งหน้าอาจลดจำนวนการอ่านของ Firestore ส่วนใน PostgreSQL อาจลดข้อมูลส่งออกและงานประมวลผล หากการเขียนหนึ่งเหตุการณ์ต้องแก้ข้อมูลซ้ำหลายแห่ง การเปลี่ยนรูปข้อมูลอาจมีผลมากกว่าการเปลี่ยนแพ็กเกจ ตัวเลขประมาณการจึงควรปรับตามรูปแบบข้อมูลที่ทีมตั้งใจใช้จริง ไม่ใช่ถือว่าทุกคำขอมีต้นทุนคงเดิม

Realtime ต้องคิดถึงผู้รับและการเชื่อมต่อใหม่

ผู้ใช้ที่เปิดหน้าติดตามข้อมูลไม่ได้สร้างภาระเฉพาะตอนข้อมูลเปลี่ยน การเริ่มติดตามต้องส่งผลลัพธ์ตั้งต้น และการกลับมาเชื่อมต่ออาจทำให้ต้องอ่านผลลัพธ์อีกครั้งตามพฤติกรรมของ SDK และการเก็บข้อมูลออฟไลน์ หากหน้าจอหนึ่งติดตามรายการกว้างเกินความจำเป็น ทุกการเปลี่ยนแปลงที่เข้าผลลัพธ์อาจไปถึงผู้ใช้จำนวนมาก จึงต้องระบุทั้งขอบเขตข้อมูลที่แต่ละกลุ่มติดตาม ความถี่ของการเปลี่ยนแปลง และจำนวนผู้ฟังพร้อมกัน

ใน Supabase วิธีนับข้อความ Realtime กำหนดว่าการเปลี่ยนฐานข้อมูลหนึ่งครั้งนับหนึ่งข้อความต่อไคลเอนต์ที่รับเหตุการณ์ ส่วน Broadcast นับข้อความที่ส่งหนึ่งครั้งและข้อความที่ผู้ติดตามแต่ละรายได้รับ; แผน Pro รวม 5 ล้านข้อความก่อนคิดส่วนเกิน ดังนั้นเหตุการณ์เดียวที่กระจายไปหลายคนมีหน่วยคิดเงินมากกว่าหนึ่งข้อความ การคำนวณต้องแยก Database Changes, Broadcast และรูปแบบการติดตามที่แอปเลือก เพราะหน่วยข้อความของแต่ละแบบไม่เหมือนจำนวนแถวที่เขียน

ใน Firestore listener ผูกกับผลลัพธ์ของคำค้น การเพิ่มหรือแก้เอกสารที่อยู่ในผลลัพธ์ทำให้เกิดการอ่านที่คิดเงินกับผู้ฟังที่ได้รับการเปลี่ยนแปลง การลบเอกสารกับการหลุดจากผลลัพธ์เพราะค่าฟิลด์เปลี่ยนยังมีผลต่อการคิดเงินต่างกัน การออกแบบหน้าสถานะคำสั่งซื้อให้ผู้ใช้ติดตามเฉพาะคำสั่งซื้อของตน จึงให้รูปโหลดคนละแบบกับหน้าที่ทุกคนติดตามรายการรวม แม้ฐานข้อมูลจะมีจำนวนการเขียนเท่ากัน

ต้นทุนย้ายขึ้นกับรูปข้อมูลและบริการที่แอปผูกไว้

Supabase มี PostgreSQL เป็นฐาน จึงมีเส้นทางตรงกว่าเมื่อจะนำตาราง ความสัมพันธ์ และคำสั่ง SQL ไปใช้กับ PostgreSQL ที่อื่น อย่างไรก็ดี การย้ายฐานข้อมูลไม่ใช่การย้ายแอปทั้งหมด: การยืนยันตัวตน กฎการเข้าถึง ไฟล์ งานเรียลไทม์ และโค้ดที่เรียกบริการของแพลตฟอร์มยังต้องจัดการแยก ความสะดวกในการย้ายจึงต้องดูว่าระบบพึ่งส่วนใดของ Supabase มากเพียงใด

Firestore เก็บข้อมูลเป็นเอกสารและคอลเลกชัน หากจะย้ายไปฐานข้อมูลเชิงสัมพันธ์ ทีมต้องตัดสินใจใหม่ว่าเอกสารใดควรเป็นตาราง ความสัมพันธ์ใดควรใช้คีย์ และข้อมูลที่ฝังหรือเก็บซ้ำควรอยู่ที่ใด คำค้นและโค้ดฝั่งแอปที่คาดว่าจะได้รับเอกสารตามรูปเดิมอาจต้องเปลี่ยนด้วย ในทางกลับกัน การย้ายจากตารางไปเป็นเอกสารก็ต้องออกแบบว่าหน้าจอจะอ่านข้อมูลร่วมกันอย่างไร การส่งออกข้อมูลเป็นเพียงส่วนหนึ่งของต้นทุนย้าย

หากผลิตภัณฑ์ยังไม่รู้ว่ารายงานและความสัมพันธ์จะซับซ้อนเพียงใด ความยืดหยุ่นของ SQL อาจมีน้ำหนักมากกว่าค่าบริการช่วงเริ่มต้น หากรูปข้อมูลและหน้าจอค่อนข้างนิ่ง การออกแบบเอกสารสำหรับการอ่านตรงทางอาจคุ้มกับงานดูแลข้อมูลที่เก็บซ้ำ การตัดสินใจนี้ควรมองอายุการใช้งานของผลิตภัณฑ์ เพราะการเปลี่ยนแบบจำลองหลังมีข้อมูลและผู้ใช้แล้วกระทบทั้งขั้นตอนย้ายข้อมูลและพฤติกรรมของแอป

Benchmark บอกอะไรได้เมื่อเงื่อนไขตรงกัน

ใน รายงานของ João Pedro Soares ลงวันที่ 24 มีนาคม 2024 ผู้เขียนกล่าวถึงการเปรียบเทียบ Firebase กับ Supabase จากงานก่อนหน้า แต่การทดลองด้านประสิทธิภาพที่ทำเองจับคู่ Supabase กับ PocketBase และวัดการเรียก API ซ้ำ 10 ครั้งบนฮาร์ดแวร์และรูปแบบติดตั้งต่างกัน ผลส่วนนั้นจึงไม่ใช่คะแนนความเร็วโดยตรงระหว่าง Supabase กับ Cloud Firestore การหยิบตัวเลขจากกราฟไปประกาศผู้ชนะของคู่นี้จะเปลี่ยนทั้งคู่เปรียบเทียบและเงื่อนไขทดสอบ

แม้ benchmark จะเทียบผลิตภัณฑ์ตรงกัน ก็ต้องดูว่าคำขอคืนข้อมูลขนาดเท่าไร เขียนหรืออ่านกี่รายการ มีดัชนีแบบใด และทดสอบในภูมิภาคใด ฐานข้อมูลที่อยู่ใกล้ผู้ใช้ในไทยอาจให้เวลาตอบสนองต่างจากการติดตั้งอีกภูมิภาคหนึ่งโดยที่ตัวฐานข้อมูลไม่ได้เปลี่ยน หากการทดลองหนึ่งใช้ข้อมูลขนาดเล็กและอีกการทดลองใช้ข้อมูลจริงที่มีความสัมพันธ์หลายชั้น ผลด้านเวลาและค่าใช้จ่ายก็ใช้แทนกันไม่ได้

เมื่อความเร็วเป็นตัวตัดสิน ให้ใช้ชุดข้อมูลและผลลัพธ์ที่แอปต้องการเหมือนกันทั้งสองทาง วัดการอ่านครั้งแรก การเขียนช่วงสูงสุด และเวลาที่การเปลี่ยนแปลงไปถึงผู้รับจากภูมิภาคที่ตั้งใจใช้งานจริง แล้วอ่านค่าควบคู่กับหน่วยคิดเงินของแต่ละบริการ หากผลต่างด้านเวลาเล็กแต่รูปข้อมูลของทางหนึ่งทำให้ต้องเก็บสำเนาหรือเขียนโค้ดชดเชยมาก ต้นทุนดูแลระยะยาวอาจมีน้ำหนักมากกว่าตัวเลขความเร็วจากการทดสอบครั้งเดียว

เงื่อนไขใดชี้ขาดการเลือก

เลือก PostgreSQL ผ่าน Supabase เมื่อธุรกรรม ความสัมพันธ์ของข้อมูล และคำถามแบบ SQL เป็นแกนของแอป พร้อมจัดงบสำหรับ instance ที่รับช่วงโหลดสูงได้ เลือก Cloud Firestore เมื่อการอ่านเอกสารตามรูปแบบหน้าจอและการติดตามผลลัพธ์เป็นงานหลัก โดยประมาณจำนวนเอกสารที่อ่าน เขียน และส่งถึงผู้ฟังได้ชัด หากรูปข้อมูลเข้ากับทั้งสองทาง ให้ใช้แบบจำลองโหลดและการทดสอบในภูมิภาคจริงตัดสิน เพราะงานอ่าน งานเขียน และเรียลไทม์ผลักต้นทุนไปคนละจุดของแต่ละระบบ