Fly Postgres ที่ Supabase ดูแลจัดการ
(supabase.com)- ความร่วมมือด้าน Managed Postgres ระหว่าง Supabase และ Fly.io มีเป้าหมายเพื่อให้ใช้ความสามารถด้านฐานข้อมูลของ Supabase บนโครงสร้างพื้นฐานของ Fly แต่ตอนนี้โครงการนี้ถูกยกเลิกแล้ว
- บริการนี้ตั้งเป้าที่จะวาง Postgres บนสภาพแวดล้อม edge computing ที่รันอยู่ใน มากกว่า 37 โลเคชัน ของ Fly.io เพื่อให้แอปพลิเคชันบน Fly อยู่ใกล้กับฐานข้อมูลมากขึ้น
- ขอบเขตความสามารถครอบคลุม ส่วนขยายมากกว่า 40 รายการ, pgvector, Supavisor, การสำรองข้อมูลรายวัน, การกู้คืน ณ จุดเวลาใดเวลาหนึ่ง, branching, observability, migrations, dashboard และ API ที่สร้างอัตโนมัติทั้ง REST และ GraphQL
- การเปิดใช้งานช่วงแรกดำเนินไปแบบค่อยเป็นค่อยไป โดยยังมี งานรวมระบบระหว่างบริษัท เช่น การเรียกเก็บเงิน การโอนย้ายการสนับสนุน และการอบรมภายใน รวมถึงการแก้บั๊กจากผู้ทดสอบช่วงแรก
- ขณะที่ Postgres แบบเดิมของ Fly เป็นแบบไม่จัดการและให้ผู้ใช้รับผิดชอบการดูแลเอง Fly Postgres เป็น บริการแบบจัดการ ที่ Supabase รับหน้าที่ดูแลการสเกล การสำรองข้อมูล การทำสำเนา และการอัปเกรด
สถานะการเปิดตัวและขอบเขตของบริการ
- ตอนนี้ Fly Postgres ถูกยกเลิกแล้ว โดยดูรายละเอียดเพิ่มเติมได้ใน ประกาศการยกเลิก
- Supabase และ Fly.io เปิดตัว Fly Postgres ในฐานะบริการ Managed Postgres ที่ทำงานบนโครงสร้างพื้นฐานของ Fly
- ฐานข้อมูลจะทำงานบนแพลตฟอร์ม edge computing ของ Fly.io และสามารถเริ่มต้นได้โดยเลือกจาก มากกว่า 37 โลเคชัน ของ Fly.io
- แอปพลิเคชันที่ใช้ข้อมูลเข้มข้นซึ่งดีพลอยบน Fly สามารถคาดหวัง latency ที่ต่ำลงได้จากการวางฐานข้อมูลไว้ในโครงสร้างพื้นฐานเดียวกัน
ความสามารถของ Supabase Managed Postgres
- Fly Postgres มอบความสามารถหลักที่คาดหวังจากฐานข้อมูลแบบจัดการของ Supabase ภายในสภาพแวดล้อมของ Fly
- ส่วนขยายมากกว่า 40 รายการ ของ Supabase Postgres
- รองรับ workload แบบ Vector/AI ที่ใช้ pgvector
- Supavisor ตัว connection pooler สำหรับ Postgres ของ Supabase
- การสำรองข้อมูลรายวันและการกู้คืน ณ จุดเวลาใดเวลาหนึ่ง
- branching, observability, migrations
- dashboard สำหรับจัดการฐานข้อมูล
- Data API ที่สร้างอัตโนมัติ
- REST API ที่ใช้ PostgREST
- GraphQL API ที่ใช้ pg_graphql
การทยอยเปิดตัวและการทดสอบช่วงแรก
- การเปิดตัวดำเนินการแบบ ทยอยเปิดใช้
- การรวมระบบระหว่างบริษัทครอบคลุมงานอย่างการเรียกเก็บเงิน การโอนย้ายการสนับสนุน และการอบรมพนักงานของ Supabase
- มีการตรวจสอบร่วมกับผู้ทดสอบช่วงแรกบางส่วน และยังมีบั๊กที่ต้องแก้ไขอยู่
- ผู้ที่ต้องการเข้าร่วมการทดสอบสามารถลงทะเบียนใน waitlist ได้
- มีแผนจะรับผู้ทดสอบเพิ่มในเดือนถัดไป และจะแชร์กำหนดการเปิดตัวเพิ่มเติมหลังมั่นใจในความปลอดภัยของข้อมูล
ความแตกต่างระหว่าง Postgres แบบจัดการและไม่จัดการ
- วิธีให้บริการ Postgres แบบเดิมของ Fly เป็นแบบ ไม่จัดการ
- ผู้ใช้ต้องจัดการเองทั้งการสเกล การสำรองข้อมูลแบบ point-in-time การทำสำเนา และการอัปเกรดเวอร์ชันหลัก
- ใน Managed Postgres ของ Fly ที่ Supabase ดูแล ผู้ใช้สามารถโฟกัสกับการสร้างแอปพลิเคชันได้มากขึ้น
- บริการแบบจัดการนี้สร้างขึ้นด้วย Fly extension API
- API เดียวกันนี้ถูกใช้กับ Fly Redis ด้วย
- ผู้ทดสอบสามารถสร้างฐานข้อมูล Postgres ได้ด้วยคำสั่ง
fly extensionsfly extensions supabase create
- เมื่อบริการมีเสถียรภาพแล้ว มีแผนจะเปลี่ยนไปใช้ namespace
postgresfly postgres create
การใช้งานที่สร้างบน Fly Machines
- Fly Postgres ถูกสร้างขึ้นบน Fly machines
- Machines คือ Firecracker VM แบบ lightweight และ Machines API ช่วยควบคุม lifecycle ของแอปพลิเคชันได้อย่างละเอียด
- Machines สามารถถูกหยุดเมื่อไม่มีการใช้งาน และกลับมาทำงานได้ภายในไม่กี่วินาทีเมื่อมีคำขอใหม่เข้ามา
- Supabase สร้าง TypeScript wrapper ชื่อ fly-admin เพื่อทำให้การโต้ตอบกับ Fly API ง่ายขึ้น
- เนื่องจาก Supabase รวมบริการเพิ่มเติมบางอย่างเข้ากับ Postgres จึงเตรียม Docker image เดียวที่ส่งต่อให้ Fly Machines API ได้
- กระบวนการ build เดิมใช้ Packer เพื่อสร้าง AMI สำหรับ AWS และมีการนำบางส่วนของ pipeline นี้กลับมาใช้ในการ build All In One Image
- All In One Image รวมทุกบริการที่จำเป็นต่อการรันโปรเจ็กต์ Supabase ไว้ใน Docker container เดียว
การเปลี่ยนผ่านสู่มัลติคลาวด์
- การเปิดตัวครั้งนี้ทำให้ Supabase กลายเป็น มัลติคลาวด์ อย่างเป็นทางการ
- Supabase ตั้งใจหลีกเลี่ยงบริการแบบจัดการของ AWS เพื่อทำให้การเปลี่ยนไปสู่มัลติคลาวด์ง่ายขึ้น
- เนื่องจาก primitive พื้นฐานของผู้ให้บริการคลาวด์แต่ละรายแตกต่างกันมาก การย้ายจึงไม่ใช่เรื่องง่าย
- Fly Machines มอบแนวทางหยุด VM ที่ไม่ได้ใช้งานและกลับมาทำงานต่อได้อย่างโปร่งใสภายในไม่กี่วินาที
- ทำให้กระบวนการ pause ฐานข้อมูลที่ไม่มีการใช้งานง่ายขึ้น
- บน AWS ไม่มี primitive ที่ทำสิ่งนี้ได้โดยตรง
- ในทางกลับกัน Fly ก็ไม่มี primitive บางอย่างที่ AWS มี ทำให้ต้องใช้วิธีอ้อม
- Fly Machines ไม่มี network-attached storage
- Supabase ปฏิบัติต่อข้อมูลใน Fly volumes เป็นข้อมูลชั่วคราว
- มีการทำ physical backup ด้วย WAL-G สำหรับทุกโปรเจ็กต์ที่รันบน Fly
- การเปลี่ยนแปลงของฐานข้อมูลจะถูกสตรีมไปยัง S3 อย่างต่อเนื่อง
- หากโฮสต์หรือวอลุ่มเสียหาย จะกู้คืนโปรเจ็กต์ไปยังโฮสต์ Fly ใหม่ด้วยข้อมูลล่าสุดจาก S3
การสังเกตการณ์การดำเนินงานและการปล่อยอิมเมจ
- บน AWS มีการรับ AWS Health events เพื่อจับปัญหาของโฮสต์
- บน Fly มีการส่ง Machine logs ไปยัง Logflare ผ่าน fly-log-shipper
- Supabase เผยแพร่ All In One image ไม่เพียงใน AWS container registry แต่ยังรวมถึง Fly Docker registry ด้วย
- การเผยแพร่ไปยัง Fly Docker registry ช่วยปรับปรุง ความน่าเชื่อถือและประสิทธิภาพ เมื่อเริ่มโปรเจ็กต์บน Fly
Fly Extensions และการรวมระบบยืนยันตัวตน
- Fly มี Extensions API สำหรับการขยายแพลตฟอร์ม
- Supabase เพิ่ม route บางรายการใน API เพื่อ provision ผู้ใช้และโปรเจ็กต์
- ผู้ใช้ Fly สามารถเข้าถึง Supabase dashboard ได้ด้วย ข้อมูลรับรองของ Fly ที่มีอยู่เดิม
- Supabase API เริ่มต้น OAuth flow กับ Fly เพื่อยืนยันตัวตนผู้ใช้
- ทีม Supabase Auth สร้าง Fly OAuth provider เพื่อให้รวม API ได้ง่ายขึ้น
งานที่ยังเหลืออยู่
- Supabase ยังคงทำงานร่วมกับทีม Fly เพื่อจัดการความท้าทายด้านปฏิบัติการบางอย่างต่อไป
-
การรองรับ network restrictions
- ฟีเจอร์ network restrictions ต้องการให้ container ได้รับ IP ที่ถูกต้องของไคลเอนต์ที่เชื่อมต่อ
- ในการตั้งค่าปัจจุบัน container เห็น IP ของ Fly proxy แทน IP ของไคลเอนต์
- การเชื่อมต่อจะผ่าน Fly proxy ที่เปิดเผย Proxy protocol
- Postgres ไม่สามารถใช้ข้อมูลนี้ได้โดยตรง และ Supabase กำลังพิจารณาทำให้ Supavisor รองรับ proxy-protocol
-
การสำรองข้อมูลภายใน Fly
- Fly ยังไม่มี managed Blob storage ดังนั้นการสำรองข้อมูลโปรเจ็กต์บน Fly จึงทำไปยัง AWS S3
- วิธีนี้ทำให้เกิดค่าใช้จ่ายด้านแบนด์วิดท์ข้ามคลาวด์
- Fly กำลังพัฒนา Blob Storage
วิธีเริ่มต้นใช้งานและราคา
- สามารถสมัครพรีวิวได้ผ่าน preview form
- เมื่อองค์กรถูกเพิ่มเข้า allow list แล้ว ก็สามารถเริ่มต้นตาม Quickstart ในเอกสารได้
- องค์กรบน Fly จะได้รับโปรเจ็กต์ฟรี 1 โปรเจ็กต์
- รายละเอียดด้านการเรียกเก็บเงินยังอยู่ระหว่างดำเนินการ แต่คาดว่าราคาจะไม่แตกต่างจากราคาปัจจุบันของ Supabase มากนัก
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
ผมเป็น CEO ของ Supabase ตอนนี้ Postgres ของ Fly เป็นแบบ ไม่ใช่บริการที่มีการจัดการ ดังนั้นเรากำลังทำงานร่วมกับ Fly เพื่อเปิดให้บริการเป็น managed service
เป็นโมเดลเดียวกับที่ทำกับทีม Upstash ใน Fly Redis: https://fly.io/docs/reference/redis/
ตอนนี้ยังอยู่ระหว่างปล่อยฟีเจอร์ high availability ให้กับผู้ทดสอบ และยังไม่มีกำหนดการที่แน่นอน แต่จะเดินหน้ากับทีม Fly ให้เร็วที่สุด
ไม่ค่อยเคยได้ยินกรณีที่บริษัทภายนอกเข้ามาร่วมมือเพื่อจัดการบริการแบบ hosted version ของบริการที่เดิมไม่ได้โฮสต์โดยบริษัทนั้น
เคยลองดู Supabase มาก่อน แต่สับสนว่ามันสร้าง REST API พื้นฐานอย่างไร
การสร้างตารางแล้วระบบสร้าง API สำหรับโต้ตอบให้อัตโนมัติดูดี แต่ถ้าอย่างนั้นควรวาง business logic ไว้ตรงไหน
ดู Edge Functions แล้วเหมือนตัวอย่างจะใกล้กับการประมวลผลงานมากกว่า เลยไม่ชัดเจนว่าควรใช้เพื่อจุดประสงค์นั้นหรือไม่ และรู้สึกเหมือนพลาดอะไรเรียบง่ายบางอย่างไป
REST API ค่อนข้างสะดวกสำหรับการรวมข้อมูลอย่าง join แต่พอถึงจุดที่ต้องใช้อะไรอย่าง transaction ก็เริ่มติดขัด
row-level security (RLS) สำหรับ role-based access control ก็น่ารำคาญ และ developer experience ยังไม่น่าประทับใจ
ถ้าความต้องการของ DB เรียบง่าย REST API ก็สะดวกมาก แต่ถ้าวางแผนทำอะไรซับซ้อน ควรเรียน PL/pgSQL หรือใช้การเชื่อมต่อ DB แบบปกติดีกว่า
ส่วนใหญ่ข้อ 1 ก็พอแล้ว ส่วนข้อ 2 และ 3 ใกล้เคียงกับเครื่องมือเสริมที่ใช้เมื่อจำเป็น
ใน use case จำนวนมากสามารถใส่ logic ไว้ใน SQL stored procedure ได้ และ PostgreSQL ก็รองรับ stored procedure ด้วย JS หรือ Python เช่นกัน
อย่างไรก็ตาม สำหรับโค้ด logic การ deploy เป็นคอนเทนเนอร์ CI/CD ปกติหรือฟังก์ชันจะให้ developer experience ดีกว่า และทั้งสองแบบก็ถูกใช้กันมากตาม trade-off ด้านต้นทุน
Supabase แนะนำ Deno serverless function แต่ถ้าเป็นเว็บโปรเจกต์ ส่วนใหญ่คงชอบ deploy Node function บน Cloudflare มากกว่า
สุดท้ายแล้วลูกค้าเป้าหมายดูเหมือนจะเป็นกลุ่มที่อยากวาง logic 99% ไว้ใน JS frontend และให้ backend จัดการแค่ CRUD กับ authentication
ส่วนนั้นเราทำ event system ที่อิงกับ Postgres WAL เพื่อจัดการเหมือน callback system
เรายังทำไลบรารีเล็ก ๆ สำหรับ Elixir ที่เริ่มจากการ fork Supabase Realtime ด้วย: https://github.com/cpursley/walex
ล่าสุดเพิ่มฟังก์ชันให้ตั้งค่า WalEx เพื่อส่ง event ไปยัง webhook หรือ EventRelay ได้ โดยไม่จำเป็นต้องรู้ Elixir
เราใช้ Next.js ดังนั้น DB call จำนวนมากอยู่ใน Next serverless function
อย่างไรก็ตาม กำลังคิดจะย้าย logic บางส่วนไปเป็น Supabase function เพื่อให้อยู่ใกล้ DB มากที่สุด แต่ยังไม่อยากย้ายไป Deno
เวลาเข้าถึง Supabase จาก server จะใช้ฟีเจอร์ PostgREST ที่ Supabase client ใช้ หรือเข้าถึง Postgres โดยตรงด้วยไลบรารี
pgทั่วไปก็ได้ตั้งตารอที่จะย้ายมาใช้สิ่งนี้ ผมสร้าง Booklet บน Fly.io และ Fly Postgres โดยจัดแอปให้เป็นแบบ distributed: https://www.contraption.co/essays/booklet-architecture/
ปัญหาใหญ่ที่สุดคือการตั้งค่า Fly Postgres โดยเฉพาะ Fly วาง HAProxy ไว้หน้า Postgres และตั้งขีดจำกัดการเชื่อมต่อ 30 นาที ทำให้การเชื่อมต่อถูกตัดอยู่เรื่อย ๆ: https://community.fly.io/t/postgresql-connection-issues-have...
มันควรเป็นปัญหาที่จัดการได้ แต่พฤติกรรมการตัดการเชื่อมต่อมีจุดแปลก ๆ ที่ไม่ตรงกับเอกสาร จึงยังไม่เสถียรอยู่เรื่อย ๆ
สงสัยว่า Postgres ตัวใหม่นี้จะยังมี HAProxy แบบเดียวกันอยู่ด้านหน้าหรือไม่
https://supabase.com/blog/supavisor-postgres-connection-pool...
https://postgrest.org/
วันนี้เห็นสิ่งนี้ในเอกสารของ Fly แล้วคิดว่าพลาดข่าวใน HN ไปหรือเปล่า แต่ปรากฏว่าเป็นของใหม่
ความคิดที่สองคือใน sidebar มีทั้ง Postgres by Fly และ Postgres by Supabase อยู่ด้วยกัน ดูแปลก ๆ
ไม่มีการเปรียบเทียบที่เห็นชัด เลยสับสนว่าถ้า deploy แอปบน Fly แล้วต้องการ Postgres ควรใช้อะไร
ส่วนตัวถ้าต้องการ DBMS บน Fly ผมคงใช้ LiteFS distributed SQLite และถ้าต้องการ Postgres ผมมองว่าความต่างระหว่าง Fly กับ Supabase โดยพื้นฐานคือแบบไม่ managed เทียบกับ managed
ดีมาก ผมไม่ค่อยชอบการตั้งค่าจำกัดเครือข่ายของ Supabase: https://supabase.com/docs/guides/platform/network-restrictio...
เท่าที่เคยดูเมื่อก่อน จำได้ว่ามีปัญหาแปลก ๆ ในการเปิดเผย IP ของแอป Fly ให้ Supabase เห็น แล้วล็อก Supabase ไว้กับ IP นั้น
การที่ Supabase เข้ามาอยู่ ภายในเครือข่ายของ Fly จริง ๆ ถือว่ายอดเยี่ยม
เอกสาร networking ของ Fly.io ก็ระบุไว้แบบนั้น
ได้ยินมาว่าเมื่อ Supabase ไปไกลกว่าระดับ prototype แล้วจะมี ปัญหาด้านการขยายระบบ เลยอยากรู้ว่ามีใครมีประสบการณ์ใช้งาน production มาเล่าได้ไหม
หมายถึงปัญหาอะไรเป็นพิเศษ?
ผม Joshua จากฝั่ง Fly.io ถ้ามีคำถามเกี่ยวกับ integration นี้ ตอบได้ครับ
ตอนนี้ใช้กับ side project บางตัวอยู่ แต่ยังไม่ได้ใช้กับโปรเจกต์ใหญ่
สิ่งต่อไปที่อยากได้คือ Blob storage เพราะโดยพื้นฐานแล้วของที่มี state อยากใช้แบบ managed เลยดีใจที่งานนั้นก็กำลังเดินหน้าอยู่
อยากรู้ว่ามีรายละเอียดเรื่องราคาของ Postgres ตัวใหม่ไหม
ตอนนี้รัน DB ขนาดใหญ่บน Fly อยู่ และกำลังหา managed PostgreSQL เลยดีใจกับข่าวนี้มาก
ทีมเราเป็นทีม Elixir ล้วน ๆ จังหวะเวลานี้ดีไปกว่านี้ไม่ได้แล้ว
“Fly machines don't have network-attached storage, so we treat any data in Fly volumes as ephemeral.”
ไม่เคยใช้ AWS และไม่ค่อยรู้จัก network-attached storage เลยสงสัยว่า Fly volumes ต่างจาก network-attached storage ของผู้ให้บริการรายอื่นอย่างไรกันแน่
จำได้ว่าถ้าสร้าง Fly volume แล้วเหมือนจะย้ายไปยังเซิร์ฟเวอร์อื่นใน region เดียวกันได้ ถ้าอย่างนั้นในเชิงเทคนิคมันไม่ใช่ network-attached storage เหรอ?
ภายในเราสามารถย้าย volume จาก physical host หนึ่งไปยังอีกเครื่องได้ วิธีทำค่อนข้างน่าสนใจ แต่ยังไม่ได้เปิดเผยต่อสาธารณะมากนัก
ภายในปีนี้น่าจะทำให้เห็นชัดขึ้น
Fly Volumes มีการ backup ไปยัง off-network block storage เป็นประจำ และเร็ว ๆ นี้จะมีประกาศเพิ่มเติมเกี่ยวกับเรื่องนี้ด้วย
สิ่งสำคัญที่ต้องเข้าใจคือ Fly Volumes ไม่ใช่ SAN storage และไม่ใช่ storage ที่มีความเสถียรโดยธรรมชาติแบบ S3
ภายใน Fly Machines มันมองเห็นเป็น filesystem ext4 ธรรมดา และถ้าต้องการเสถียรภาพ ความทนทาน หรือการทำ replication ก็ต้องจัดให้ในชั้น application
Fly Postgres ทำงานเป็นคลัสเตอร์ read replica และหากจำเป็น replica ตัวใดก็สามารถรับบทเป็น write leader แทนได้ ดังนั้นแนวทางนี้จึงเหมาะ
นี่คือเหตุผลที่ถ้าพยายามสร้างคลัสเตอร์ Postgres แบบ node เดียว เราถึงแสดงคำเตือนสีแดงใหญ่ ๆ ใน console
ในอีกไม่กี่ไตรมาสข้างหน้า เราน่าจะออกตัวเลือกใหม่ ๆ บนสเปกตรัมด้านเสถียรภาพและประสิทธิภาพ แต่คงไม่ใช่รูปแบบการรัน SAN drive เองที่แค่ expose block device แบบ iSCSI
ผมเกลียด โมเดลราคา ของสองบริษัทนี้จริง ๆ
ด้านหนึ่งคือ Supabase ซึ่งเป็นแพ็กเกจแบบ tiered สไตล์แพลตฟอร์มนักพัฒนาอย่าง Vercel โครงสร้างทำให้ต้องจ่ายมากกว่าการใช้งานจริง
อีกด้านคือ Fly ที่คิดราคาละเอียดเกินไปแบบ Lambda เป็นรายวินาที รายหน่วย memory รายหน่วย CPU ซึ่งอาจทำให้จ่ายน้อยเกินไปแล้วเจอ performance drop
มีของอย่าง Cloudflare Workers อยู่แล้ว ไม่ค่อยเข้าใจว่าทำไมต้องเลือกหนึ่งในสองนี้ ทำไมยังอยากกังวลเรื่องการ scale อยู่?
ดูแล้ว Cloudflare ก็ไม่น่าจะให้บริการ Postgres จริง ๆ ด้วย ปรัชญาของ Cloudflare คือทุกอย่างที่ deploy จะถูก deploy ไปทั่วโลก แต่ relational database บังคับให้มีเซิร์ฟเวอร์เดียวเป็นแหล่งความจริง
แน่นอนว่าถ้าพิสูจน์ได้ว่าผมคิดผิดก็คงดี
Fly มีราคาต่อเดือนที่ค่อนข้างเข้าใจง่าย และไม่เหมือน Lambda เลย ถ้าเทียบกันแล้วโมเดลราคาของ Cloudflare Workers ต่างหากที่ใกล้กับ Lambda มากกว่า