Supabase หรือ Neon: ฐานข้อมูลที่หลับได้อาจถูกกว่า จนทราฟฟิกทำงานทั้งวัน

ถ้าฐานข้อมูลว่างนานในแต่ละวันและต้องสร้างฐานข้อมูลชั่วคราวตาม pull request Neon มักเป็นตัวเลือกที่ควรคำนวณก่อน เพราะหยุดคิดค่า compute ได้เมื่อฐานข้อมูลหลับ แต่ถ้าทราฟฟิกทำให้ฐานข้อมูลทำงานต่อเนื่องและแอปต้องใช้บริการ backend หลายอย่าง Supabase อาจคุ้มกว่า ทั้งนี้ต้องเทียบขนาดเครื่องและค่าใช้จ่ายรวม ไม่ใช่ดูเพียงชั่วโมงที่เปิดฐานข้อมูล ราคา Neon Launch คิดค่า Postgres 0.106 ดอลลาร์ต่อ CU-hour และพื้นที่ฐานข้อมูล 0.35 ดอลลาร์ต่อ GB ต่อเดือน โดย compute ลดเหลือศูนย์ได้เมื่อไม่มีการใช้งาน

ราคา Supabase Pro เริ่มที่ 25 ดอลลาร์ต่อเดือน รวมเครดิต compute 10 ดอลลาร์ซึ่งพอสำหรับ Micro หนึ่งโปรเจกต์ที่ทำงานตลอดเดือน พร้อมพื้นที่ฐานข้อมูล 8 GB, ผู้ใช้ Auth รายเดือน 100,000 คน และพื้นที่เก็บไฟล์ 100 GB ดังนั้นราคาสองฝั่งจึงซื้อสิ่งต่างกัน: Neon วัดการใช้ Postgres ตามกำลังประมวลผลและเวลา ส่วน Supabase Pro ให้ฐานข้อมูลพร้อมบริการประกอบภายใต้ค่าสมาชิกและโควตา

เทียบหน่วยให้ตรงก่อนดูยอดรายเดือน

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

การเทียบ Postgres ควรกำหนดเดือน ความจุข้อมูล และขนาดเครื่องที่รองรับงานให้ชัดเจน ส่วนการเทียบ backend ต้องนับ Auth, ไฟล์, ฟังก์ชัน และการส่งข้อมูลออกด้วย ตัวอย่างต่อไปเป็นสถานการณ์สมมติในเดือน 30 วัน ใช้ราคาที่ระบุข้างต้นและยังไม่รวมภาษี ค่าโอนข้อมูล หรือการใช้เกินโควตา ตัวเลขเหล่านี้ช่วยหาเงื่อนไขที่คำตอบเปลี่ยน แต่ไม่ได้รับประกันว่าฐานข้อมูลสองขนาดจะทำงานได้เร็วเท่ากัน

เครื่องคำนวณสามสถานการณ์

งานทดลองที่ฐานข้อมูลหลับบ่อย

สมมติฐานข้อมูลขนาด 1 GB บน Neon Launch ใช้ 0.25 CU และตื่นวันละ 4 ชั่วโมง ตลอด 30 วัน เท่ากับ 30 CU-hour ค่า compute จึงเป็น 3.18 ดอลลาร์ บวกพื้นที่ฐานข้อมูล 0.35 ดอลลาร์ รวมประมาณ 3.53 ดอลลาร์ หากใช้ Supabase Pro กับ Micro และไม่เกินโควตา ยอดฐานคือ 25 ดอลลาร์ ส่วนต่างเกิดจากเวลาที่ Neon หยุดคิดค่า compute ไม่ได้เกิดจากราคาต่อชั่วโมงที่ถูกกว่าในทุกกรณี

การตื่นวันละ 4 ชั่วโมงต้องหมายถึงเวลาที่ compute ทำงานจริง คำขอเป็นระยะ งานตามเวลา และการเชื่อมต่อที่ทำให้ฐานข้อมูลไม่เข้าสู่ช่วงว่างอาจเพิ่มชั่วโมงที่ถูกคิดเงิน หากมีการเขียนข้อมูลจำนวนมาก ค่าเก็บประวัติสำหรับการกู้คืนของ Neon ยังเป็นอีกบรรทัดหนึ่งซึ่งไม่ได้อยู่ในยอด 3.53 ดอลลาร์นี้ ส่วนแผนฟรีของทั้งสองบริการมีโควตาและพฤติกรรมต่างจากตัวอย่างแบบชำระเงิน จึงไม่ควรนำยอดศูนย์ดอลลาร์มาแทนการคำนวณสำหรับระบบที่ต้องพร้อมรับคำขอจริง

SaaS ที่มีทราฟฟิกสม่ำเสมอ

สมมติฐานข้อมูลขนาด 1 GB ต้องใช้ Neon เฉลี่ย 1 CU ตลอด 24 ชั่วโมงในเดือน 30 วัน ค่า compute จะเป็น 76.32 ดอลลาร์ บวกพื้นที่ 0.35 ดอลลาร์ รวมประมาณ 76.67 ดอลลาร์ ฝั่ง Supabase Pro หากเลือก Medium ซึ่งมีหน่วยความจำ 4 GB จะจ่าย 25 ดอลลาร์สำหรับแผน บวกค่า compute 60 ดอลลาร์ แล้วหักเครดิต 10 ดอลลาร์ เหลือ 75 ดอลลาร์เมื่อไม่มีรายการอื่นเกินโควตา ในเงื่อนไขนี้ข้อได้เปรียบจากการหลับหายไป และ Neon สูงกว่าเล็กน้อย

เส้นที่ยอดสองฝั่งใกล้กันอยู่ราว 704 ชั่วโมงต่อเดือน หรือประมาณ 23.5 ชั่วโมงต่อวัน: นำ 75 ดอลลาร์ลบค่าพื้นที่ Neon 0.35 ดอลลาร์ แล้วหารด้วย 0.106 ดอลลาร์ต่อ CU-hour แต่เส้นนี้ใช้ได้เฉพาะการสมมติให้ Neon เฉลี่ย 1 CU เทียบกับ Supabase Medium หาก Neon ใช้เพียง 0.25 CU ตลอด 720 ชั่วโมง ค่า compute กับพื้นที่จะอยู่ประมาณ 19.43 ดอลลาร์ ซึ่งยังต่ำกว่า Supabase Pro พร้อม Micro ที่ 25 ดอลลาร์ ขนาด CU เฉลี่ยที่ autoscaling ใช้จริงจึงสำคัญพอ ๆ กับจำนวนชั่วโมง

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

ฐานข้อมูล preview ต่อ pull request

สมมติมี preview 8 ชุด แต่ละชุดใช้ Neon ที่ 0.25 CU เป็นเวลา 10 ชั่วโมง รวม 80 ชั่วโมงที่ compute ทำงาน หรือ 20 CU-hour คิดเป็น 2.12 ดอลลาร์เพิ่มจากฐานข้อมูลหลัก เมื่อรวม branch หลักแล้วจำนวน branch ที่มีพร้อมกันยังอยู่ในโควตา Launch ฝั่ง Supabase หาก preview ทุกชุดเป็น Micro และแต่ละชุดมีอายุ 10 ชั่วโมง ค่า compute รวมประมาณ 1.08 ดอลลาร์เพิ่มจากแผนและโปรเจกต์หลัก ตัวอย่างนี้แสดงว่า Neon ไม่ได้ถูกกว่าทุกบรรทัดของบิล preview

ผลจะเปลี่ยนถ้าแต่ละ preview มีอายุ 48 ชั่วโมง แต่ Neon ทำงานจริงเพียง 10 ชั่วโมงต่อชุด: ค่า compute Neon ในสมมติฐานเดิมยังเป็น 2.12 ดอลลาร์ ขณะที่ Micro ของ Supabase ซึ่งคิดตามเวลาที่โปรเจกต์ทำงานจะอยู่ราว 5.16 ดอลลาร์สำหรับ 8 ชุด ยังต้องบวกค่าเก็บข้อมูลที่เปลี่ยนบน Neon หรือการใช้ทรัพยากรอื่นบน Supabase ความต่างระหว่าง อายุของ branch กับ ชั่วโมงที่ฐานข้อมูลตื่น จึงเป็นหัวใจของงาน preview ที่เปิดค้างหลังการทดสอบจบ

คำขอแรกหลังหลับมีต้นทุนเป็นเวลารอ

เมื่อ Neon หยุด compute คำขอแรกต้องรอให้ฐานข้อมูลกลับมาทำงาน ในการทดสอบของ BetterDevTool ซึ่งใช้ไคลเอนต์และฐานข้อมูลใน AWS us-east-1 คำขอแรกหลังว่าง 10 นาทีใช้ 612 มิลลิวินาทีบน Neon เทียบกับ 34 มิลลิวินาทีบน Supabase Pro ส่วนการอ่านแบบอุ่นมีค่ากลาง 3.4 และ 3.1 มิลลิวินาทีตามลำดับ การทดสอบใช้ Supabase Micro กับ Neon Launch ที่ autoscale ระหว่าง 0.25–2 CU และรายงานค่ากลางจากการวัดห้าครั้ง จึงเป็นผลของการตั้งค่านั้น ไม่ใช่เวลารอคงที่ในทุกภูมิภาค

ในชุดทดสอบเดียวกัน Supabase ทำงานอ่านเขียนแบบ pgbench ได้ throughput สูงกว่า Neon ราว 34% ส่วน Neon ทำงานอ่านอย่างเดียวได้มากกว่าเมื่อ autoscaling เพิ่มทรัพยากรระหว่างทดสอบ ผลสองอย่างนี้วัดภาระงานต่างกัน จึงใช้สลับกันตัดสินแอปไม่ได้ สำหรับแอปที่ผู้ใช้กลับมาเปิดหลังช่วงเงียบ ควรแยกเวลาของคำขอแรกออกจากคำขอถัดไป เพราะฐานข้อมูลที่อุ่นแล้วอาจตอบเร็ว แต่ผู้ใช้ยังสัมผัสช่วงรอเริ่มต้นทุกครั้งที่ compute หลับ

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

Branch ต่างกันทั้งข้อมูลตั้งต้นและวิธีคิดเงิน

คู่มือ branching ของ Neon ระบุว่า branch ใหม่เริ่มพร้อม schema และข้อมูลของ parent โดยการเปลี่ยนแปลงใน branch ไม่กระทบต้นทาง จึงเหมาะกับการลอง migration หรือ query บนข้อมูลที่ใกล้สภาพจริง หากข้อมูล production อ่อนไหว สามารถเลือก branch ที่คัดลอกเฉพาะ schema แล้วเติมข้อมูลทดสอบที่เหมาะสมแทน Neon ยังตั้งเวลาหมดอายุเพื่อลบ branch ชั่วคราวได้

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

คู่มือ branching ของ Supabase อธิบายว่า preview เป็น environment แยกพร้อมการตั้งค่า Auth, Data API, Realtime, Storage และ Edge Functions จากโปรเจกต์หลัก แต่ตามค่าเริ่มต้นไม่มีแถวข้อมูลหรือไฟล์จาก production สำหรับ branch ที่เชื่อม GitHub ระบบสร้าง schema จาก migration ใน repository; branch ที่สร้างผ่าน Dashboard ใช้ประวัติ migration ของโปรเจกต์หลัก ทีมที่ต้องการข้อมูลทดสอบสามารถใช้ seed หรือเลือกนำข้อมูลเข้าตามวิธีสร้าง branch

รูปแบบนี้มีผลต่อขั้นตอนพัฒนา: Neon เหมาะเมื่อการทดสอบต้องเริ่มจากข้อมูลของ parent ส่วน Supabase เหมาะเมื่อทีมต้องการ preview ของบริการหลายส่วนและให้ schema เดินตาม migration ที่จะปล่อยจริง Preview ของ Supabase ที่ผูกกับ pull request ถูกลบเมื่อรวมโค้ดหรือปิดคำขอ แต่ระหว่างที่ยังเปิดอยู่ต้องนับค่า compute ของโปรเจกต์แยกจากฐานข้อมูลหลักทั้งช่วงเวลาที่ใช้งาน การลบหรือกำหนดอายุ branch ให้ตรงกับวงจรงานจึงช่วยควบคุมค่าใช้จ่ายได้ทั้งสองฝั่ง

Auth, ไฟล์ และฟังก์ชันเปลี่ยนยอดรวม

Neon มี Managed Better Auth, Object Storage และ Functions ในแพลตฟอร์มแล้ว จึงไม่จำเป็นต้องสมมติว่าทุกทีมต้องซื้อบริการเหล่านี้ภายนอก แต่ CU-hour วัดเฉพาะ compute ของ Postgres; พื้นที่ไฟล์ การทำงานของ Functions และการส่งข้อมูลออกมีอัตราหรือโควตาแยกกัน ฝั่ง Supabase Pro รวมโควตา Auth, Storage, Realtime และ Edge Functions ไว้ในแผนก่อนคิดส่วนเกิน การนำราคา Postgres ของ Neon ไปเทียบกับราคา backend ทั้งชุดของ Supabase โดยไม่แจกแจงบริการจึงทำให้ผลคลาดเคลื่อน

ตัวอย่างสมมติ แอปเก็บไฟล์ 20 GB บน Neon Launch ที่อัตรา 0.023 ดอลลาร์ต่อ GB ต่อเดือน จะมีค่าเก็บไฟล์ประมาณ 0.46 ดอลลาร์ โดยยังไม่คิดการส่งข้อมูลออก ปริมาณไฟล์เท่ากันอยู่ภายในโควตาพื้นที่ไฟล์ของ Supabase Pro แต่แอปที่มีการดาวน์โหลดจำนวนมากยังต้องดู egress แยกจากพื้นที่เก็บ บิลไฟล์จึงขึ้นกับทั้งข้อมูลที่ค้างอยู่และข้อมูลที่ส่งถึงผู้ใช้

Auth ต้องเทียบจากจำนวนผู้ใช้รายเดือนและความสามารถที่แอปต้องการ Neon ระบุ Managed Better Auth ในแผนปัจจุบัน ส่วน Supabase Pro มีโควตา Auth ของตนเอง หากทีมมีระบบยืนยันตัวตนภายนอกอยู่แล้ว ต้นทุนสัญญาเดิมอาจไม่เปลี่ยนตามฐานข้อมูลที่เลือก แต่หากจะย้าย Auth ไปพร้อมกัน ต้องนับงานย้ายผู้ใช้และการเชื่อมต่อแอปเป็นต้นทุนของการตัดสินด้วย สำหรับ Functions ควรแยกเวลาที่กำลังประมวลผล จำนวนครั้งที่เรียก และโควตาที่แต่ละแผนให้ไว้ก่อนรวมยอด

เลือกตามภาระงานที่ต้องรับจริง

Neon เหมาะกับฐานข้อมูลที่มีช่วงว่างชัดเจน งานทดลองที่ใช้กำลังประมวลผลเป็นพัก ๆ และ preview ที่ต้องการข้อมูลจาก parent โดยทีมยอมรับเวลารอคำขอแรกได้ หากทราฟฟิกถี่ขึ้นจน compute แทบไม่หลับ ให้ดู CU เฉลี่ยที่ autoscaling ใช้ ไม่ใช่เพียงจำนวนชั่วโมงเปิดบริการ ส่วนค่า branch และประวัติข้อมูลจะเด่นขึ้นเมื่อมี preview หลายชุดหรือปล่อยไว้หลายวัน

Supabase เหมาะกับแอปที่ต้องตอบคำขอต่อเนื่องและใช้ Auth, ไฟล์, API หรือฟังก์ชันร่วมกับฐานข้อมูลในโปรเจกต์เดียว โดยเฉพาะทีมที่ต้องการ preview ซึ่งเริ่มจาก migration และไม่พาข้อมูล production เข้าไปตามค่าเริ่มต้น สำหรับทีมในไทย เวลาตอบกลับที่ผู้ใช้สัมผัสยังขึ้นกับภูมิภาคที่เลือกและตำแหน่งของแอปด้วย ข้อสรุปด้านราคาให้ยึดชั่วโมงทำงาน ขนาด compute และบริการที่แอปใช้จริง ส่วนข้อสรุปด้านความเร็วให้ยึดภาระงานและเส้นทางคำขอของแอปนั้น

อ่านเพิ่มเติม:

• Cloudflare Workers หรือ Vercel Functions: cold start ไม่ใช่ต้นทุนเดียว
• Supabase หรือ Firebase: งานอ่านกับงานเขียนให้คำตอบคนละแบบ