Fly Postgres yang Dikelola Supabase

 (supabase.com)
2 poin oleh GN⁺ 2023-12-17 | 1 komentar | Bagikan ke WhatsApp
  • Kolaborasi Postgres terkelola antara Supabase dan Fly.io ditujukan untuk menghadirkan kemampuan basis data Supabase di infrastruktur Fly, tetapi saat ini sudah dihentikan
  • Layanan ini menargetkan penempatan Postgres di lingkungan edge computing yang berjalan di lebih dari 37 lokasi milik Fly.io, agar aplikasi Fly dan basis data berada lebih dekat
  • Cakupan fiturnya mencakup lebih dari 40 ekstensi, pgvector, Supavisor, backup harian, pemulihan ke titik waktu tertentu, branching, observabilitas, migrasi, dashboard, hingga API otomatis REST·GraphQL
  • Deployment awal dilakukan secara bertahap, dengan pekerjaan integrasi antarperusahaan seperti penagihan, alih dukungan, pelatihan internal, serta perbaikan bug dari penguji awal yang masih tersisa
  • Berbeda dari Postgres Fly yang sudah ada dan bersifat tidak dikelola sehingga tanggung jawab operasional ada pada pengguna, Fly Postgres adalah layanan terkelola di mana Supabase menangani penskalaan, backup, replikasi, dan upgrade

Status peluncuran dan cakupan layanan

  • Fly Postgres saat ini sudah dihentikan; detail lebih lanjut dapat dilihat di pengumuman penghentian
  • Supabase dan Fly.io meluncurkan Fly Postgres sebagai layanan Postgres terkelola yang berjalan di infrastruktur Fly
  • Basis data berjalan di platform edge computing milik Fly.io, dan bisa dimulai dengan memilih salah satu dari lebih dari 37 lokasi Fly.io
  • Aplikasi intensif data yang di-deploy di Fly dapat mengharapkan latensi lebih rendah dengan menempatkan basis data di infrastruktur yang sama

Fitur Postgres terkelola Supabase

  • Fly Postgres menghadirkan fitur-fitur utama yang diharapkan dari basis data terkelola Supabase ke lingkungan Fly
    • Lebih dari 40 ekstensi dari Supabase Postgres
    • Dukungan workload Vector/AI berbasis pgvector
    • Supavisor, connection pooler Postgres dari Supabase
    • Backup harian dan pemulihan ke titik waktu tertentu
    • Branching, observabilitas, migrasi
    • Dashboard untuk pengelolaan basis data
    • Data API yang dihasilkan otomatis

Peluncuran bertahap dan pengujian awal

  • Peluncuran dilakukan secara bertahap
  • Integrasi antarperusahaan mencakup pekerjaan seperti penagihan, alih dukungan, dan pelatihan karyawan Supabase
  • Layanan ini sedang divalidasi bersama sebagian penguji awal, dan masih ada bug yang perlu diperbaiki
  • Siapa pun yang ingin ikut pengujian dapat mendaftar ke waitlist
  • Saat itu, ada rencana menerima lebih banyak penguji pada bulan berikutnya dan membagikan jadwal peluncuran tambahan setelah yakin dengan keamanan data

Perbedaan Postgres terkelola dan tidak terkelola

  • Penawaran Postgres Fly yang sudah ada bersifat tidak terkelola
    • Pengguna harus menangani sendiri penskalaan, backup point-in-time, replikasi, upgrade versi mayor, dan lainnya
  • Dengan Postgres terkelola milik Fly yang dioperasikan oleh Supabase, pengguna dapat lebih fokus membangun aplikasi
  • Layanan terkelola ini dibuat dengan Fly extension API
    • API yang sama juga digunakan untuk Fly Redis
  • Penguji dapat membuat basis data Postgres dengan perintah fly extensions
    • fly extensions supabase create
  • Setelah layanan stabil, namespace ini direncanakan diganti menjadi postgres
    • fly postgres create

Implementasi berbasis Fly Machines

  • Fly Postgres dibangun di atas Fly machines
  • Machines adalah VM Firecracker yang ringan, dan Machines API memberikan kontrol rinci atas siklus hidup aplikasi
  • Machines dapat dihentikan saat tidak aktif dan dilanjutkan kembali dalam beberapa detik ketika ada permintaan baru
  • Untuk menyederhanakan interaksi dengan Fly API, Supabase membuat wrapper TypeScript bernama fly-admin
  • Karena Supabase membundel beberapa layanan tambahan dengan Postgres, mereka menyiapkan satu image Docker yang bisa dikirim ke Fly Machines API
  • Proses build yang ada menggunakan Packer untuk membuat AMI bagi AWS, dan sebagian pipeline ini digunakan ulang untuk membangun All In One Image
  • All In One Image mencakup semua layanan yang diperlukan untuk menjalankan proyek Supabase di dalam satu container Docker

Transisi multicloud

  • Dengan peluncuran ini, Supabase secara resmi menjadi multicloud
  • Supabase sengaja menghindari layanan terkelola AWS untuk menyederhanakan transisi ke multicloud
  • Primitive dasar berbeda cukup besar di tiap penyedia cloud, sehingga transisi tidak sesederhana itu
  • Fly Machines menyediakan cara untuk menghentikan VM yang tidak digunakan dan melanjutkannya kembali secara transparan dalam beberapa detik
    • Ini menyederhanakan proses menjeda basis data yang tidak aktif
    • AWS tidak memiliki primitive untuk mencapai ini secara langsung
  • Sebaliknya, Fly tidak memiliki beberapa primitive yang disediakan AWS sehingga perlu solusi alternatif
    • Fly Machines tidak memiliki storage yang terhubung ke jaringan
    • Supabase memperlakukan data di Fly volumes sebagai data sementara
    • Supabase melakukan backup fisik dengan WAL-G untuk semua proyek yang berjalan di Fly
    • Perubahan basis data terus-menerus di-stream ke S3
    • Jika host atau volume rusak, proyek dipulihkan ke host Fly baru menggunakan data S3 terbaru

Observabilitas operasional dan distribusi image

  • Di AWS, AWS Health events diterima untuk menangkap masalah host
  • Di Fly, log Machine dikirim ke Logflare melalui fly-log-shipper
  • Supabase memublikasikan All In One image tidak hanya ke registry container AWS tetapi juga ke Fly Docker registry
  • Publikasi ke Fly Docker registry meningkatkan keandalan dan performa saat memulai proyek di Fly

Integrasi ekstensi Fly dan autentikasi

  • Fly menyediakan Extensions API untuk perluasan platform
  • Supabase menambahkan beberapa route ke API untuk melakukan provisioning pengguna dan proyek
  • Pengguna Fly dapat mengakses dashboard Supabase dengan kredensial Fly yang sudah ada
  • Supabase API memulai alur OAuth dengan Fly untuk autentikasi pengguna
  • Tim Supabase Auth membuat Fly OAuth provider agar integrasi API lebih mudah

Tantangan yang tersisa

  • Supabase masih terus menangani beberapa tantangan operasional bersama tim Fly

  • Dukungan pembatasan jaringan

    • Fitur pembatasan jaringan memerlukan container menerima IP yang benar dari klien yang terhubung
    • Dalam konfigurasi saat ini, container melihat IP proxy Fly alih-alih IP klien
    • Koneksi melewati proxy Fly yang mengekspos Proxy protocol
    • Postgres tidak dapat langsung menggunakan informasi ini, dan Supabase sedang meninjau cara agar Supavisor mengenali proxy-protocol

  • Backup internal Fly

    • Fly belum menyediakan Blob storage terkelola, sehingga backup proyek Fly dilakukan ke AWS S3
    • Pendekatan ini menimbulkan biaya bandwidth antarcloud
    • Fly sedang mengerjakan Blob Storage

Cara memulai dan harga

  • Pendaftaran preview saat itu dapat dilakukan melalui preview form
  • Setelah organisasi dimasukkan ke allowlist, proses dapat dimulai lewat Quickstart di dokumentasi
  • Organisasi Fly bisa mendapatkan satu proyek gratis
  • Detail penagihan saat itu masih dikerjakan, tetapi harga diperkirakan tidak akan banyak berubah dibanding harga Supabase saat ini

Bacaan terkait

1 komentar

 
GN⁺ 2023-12-17
Opini Hacker News

  • Saya CEO Supabase. Postgres Fly saat ini tidak terkelola, jadi kami sedang bekerja untuk menjalankan layanan terkelola bersama Fly
    Modelnya sama seperti yang dilakukan dengan tim Upstash di Fly Redis: https://fly.io/docs/reference/redis/
    Kami masih sedang merilis fitur ketersediaan tinggi bersama para tester dan belum ada jadwal pasti, tetapi kami akan bergerak secepat mungkin bersama tim Fly

    • Saya penasaran mengapa Fly tidak naik ke pasar yang lebih tinggi dengan menyediakan layanan terkelola sendiri seperti DigitalOcean atau cloud besar
      Saya jarang mendengar kasus perusahaan eksternal masuk dan berkolaborasi untuk mengelola versi hosted dari layanan non-hosting milik perusahaan lain
    • Saya penasaran bagaimana pandangan Anda tentang SQLite terdistribusi. Apakah Anda melihatnya bisa menjadi pilihan default alih-alih Postgres ke depannya?

  • Dulu saya sempat melihat Supabase, tetapi bingung bagaimana membuat REST API dasarnya
    Gagasan bahwa saat membuat tabel, API untuk berinteraksi dengannya dibuat otomatis memang terlihat bagus, tetapi saya tidak tahu logika bisnis harus diletakkan di mana
    Saya juga melihat Edge Functions, tetapi contohnya lebih dekat ke pemrosesan tugas, jadi tidak jelas apakah memang harus dipakai untuk tujuan itu; rasanya seperti saya melewatkan sesuatu yang sederhana

    • Jika memakai antarmuka PostgREST, perlu diingat bahwa pada akhirnya Anda akan memasukkan logika ke stored procedure
      REST API cukup nyaman untuk agregasi data seperti join, tetapi begitu membutuhkan hal seperti transaksi, saya mulai mentok
      Row Level Security (RLS) untuk kontrol akses berbasis peran juga merepotkan, dan pengalaman pengembangnya terasa kurang memuaskan
      Jika kebutuhan DB sederhana, REST API sangat nyaman, tetapi jika merencanakan sesuatu yang kompleks, lebih baik mempelajari PL/pgSQL atau memakai koneksi DB biasa
    • Ada beberapa pilihan: terhubung langsung ke Postgres seperti DB Postgres biasa, terhubung ke PostgREST yaitu REST API otomatis yang disebutkan tadi, atau memakai Edge Functions berbasis Deno
      Bagi kebanyakan orang, opsi 1 sudah cukup, sedangkan opsi 2 dan 3 lebih seperti alat tambahan yang dipakai saat dibutuhkan
    • Komponen intinya adalah https://postgrest.org/en/stable/. Kami memakainya di produksi pada proyek perusahaan besar di atas k8s
      Untuk banyak kasus penggunaan, logika bisa dimasukkan ke stored procedure SQL, dan PostgreSQL juga memungkinkan stored procedure JS atau Python
      Namun untuk kode logika, pengalaman pengembang biasanya lebih baik jika dideploy sebagai container CI/CD biasa atau function; keduanya banyak dipakai bergantung pada kompromi biaya
      Supabase merekomendasikan function serverless Deno, tetapi untuk proyek web, saya rasa mayoritas akan lebih memilih men-deploy function Node ke Cloudflare
      Pada akhirnya, target pelanggannya tampak seperti pihak yang ingin menaruh 99% logika di frontend JS, sementara backend hanya menangani CRUD dan autentikasi
    • Kami menaruh sebagian besar logika bisnis di trigger dan constraint Postgres. Namun ada juga pekerjaan lain seperti integrasi eksternal
      Untuk bagian itu, kami membuat sistem event berbasis Postgres WAL dan menanganinya seperti sistem callback
      Kami juga membuat library kecil untuk Elixir yang awalnya dimulai sebagai fork Supabase Realtime: https://github.com/cpursley/walex
      Baru-baru ini kami menambahkan fitur untuk mengatur WalEx agar meneruskan event ke webhook atau EventRelay, sehingga tidak perlu tahu Elixir
    • DB bisa diakses dari klien maupun server, bergantung pada konfigurasi
      Karena kami memakai Next.js, banyak panggilan DB berada di dalam function serverless Next
      Namun saya juga akan melihat kemungkinan memindahkan sebagian logika ke function Supabase agar sedekat mungkin dengan DB, meski sejauh ini saya belum ingin memindahkannya ke Deno
      Saat mengakses Supabase dari server, Anda bisa memakai fitur PostgREST yang digunakan klien Supabase, atau mengakses Postgres secara langsung dengan library umum pg

  • Saya menantikan untuk beralih ke ini. Saat membangun Booklet di atas Fly.io dan Fly Postgres, saya menyusun aplikasi secara terdistribusi: https://www.contraption.co/essays/booklet-architecture/
    Masalah terbesar adalah pengaturan Fly Postgres. Terutama karena Fly menaruh HAProxy di depan Postgres dan menetapkan batas koneksi 30 menit, sehingga koneksi terus diputus: https://community.fly.io/t/postgresql-connection-issues-have...
    Ini seharusnya masalah yang bisa dikelola, tetapi perilaku pemutusan koneksinya terasa aneh karena tidak sesuai dokumentasi, jadi terus tidak stabil
    Saya penasaran apakah Postgres baru juga menaruh HAProxy yang sama di depan

  • Hari ini saya melihat ini di dokumentasi Fly dan sempat berpikir apakah saya melewatkannya di HN, ternyata memang baru dirilis
    Pikiran kedua saya adalah terasa aneh melihat Postgres by Fly dan Postgres by Supabase berdampingan di sidebar
    Tidak ada perbandingan yang menonjol juga, jadi jika saya men-deploy aplikasi ke Fly dan membutuhkan Postgres, saya bingung harus memakai yang mana
    Secara pribadi, jika membutuhkan DBMS di Fly, saya mungkin akan memakai SQLite terdistribusi LiteFS; jika membutuhkan Postgres, perbedaan antara Fly dan Supabase pada dasarnya adalah tidak terkelola vs terkelola

    • Jika membutuhkan database terkelola, pakai Supabase. Fly.io Postgres tidak terkelola, dan benar, itulah perbedaan utamanya

  • Sangat bagus. Saya kurang suka pengaturan pembatasan jaringan Supabase: https://supabase.com/docs/guides/platform/network-restrictio...
    Seingat saya, saat dulu melihatnya, ada masalah aneh ketika mengekspos IP aplikasi Fly ke Supabase lalu mengunci Supabase ke IP itu
    Bagus sekali bahwa Supabase benar-benar masuk ke dalam jaringan Fly

    • Masalahnya di sini adalah fly.io tidak menjamin konsistensi alamat IP keluar, jadi allowlist berbasis IP asal tidak bisa digunakan
      Ini juga tertulis di dokumentasi networking Fly.io

  • Saya dengar Supabase punya masalah skalabilitas begitu melewati tahap prototipe; penasaran apakah ada yang punya pengalaman produksi bisa menjelaskan

    • Karena itu Postgres yang berjalan di AWS, sepertinya akan bisa diskalakan sejauh yang diharapkan dari kombinasi tersebut
      Secara spesifik, masalah apa yang dimaksud?

  • Joshua dari Fly.io di sini. Kalau ada pertanyaan tentang integrasi ini, saya akan menjawab

    • Ini benar-benar saya nantikan. Selain kekhawatiran umum soal stabilitas, terutama masalah seputar deployment dan pesan kegagalan yang sulit dipahami, tidak adanya Postgres terkelola adalah alasan utama saya belum memakai Fly secara serius
      Saya memakainya untuk beberapa proyek sampingan, tapi belum untuk proyek besar
      Hal berikutnya yang saya harapkan adalah penyimpanan Blob; karena untuk hal-hal yang punya state pada dasarnya saya ingin memakai layanan terkelola, senang mendengar pekerjaan itu juga sedang berjalan
      Penasaran apakah ada detail tentang harga penawaran Postgres baru ini

  • Saat ini kami menjalankan DB besar di Fly dan sedang mencari PostgreSQL terkelola, jadi kabar ini sangat menggembirakan
    Kami adalah tim yang sepenuhnya memakai Elixir, jadi waktunya benar-benar pas

    • Saya penasaran apa kelebihannya dibanding sekadar mendaftar di supabase.com lalu memasukkan kredensial DB ke aplikasi Elixir

  • “Fly machines don't have network-attached storage, so we treat any data in Fly volumes as ephemeral.”
    Saya belum pernah memakai AWS dan juga kurang paham soal network-attached storage, jadi penasaran apa tepatnya perbedaan antara Fly Volumes dan network-attached storage dari penyedia lain
    Seingat saya, kalau membuat Fly Volume, itu bisa dipindahkan ke server lain di region yang sama; kalau begitu, bukankah secara teknis itu network-attached storage?

    • Bukan. Fly Volumes adalah penyimpanan NVMe yang terpasang, dan terikat pada host fisik tempat ia dibuat
      Secara internal, kami bisa memindahkan volume dari satu host fisik ke host fisik lain; caranya cukup menarik, tetapi belum banyak kami ungkapkan secara publik
      Tahun ini akan kami munculkan lebih jelas
      Fly Volumes secara berkala dicadangkan ke block storage di luar jaringan, dan akan ada pengumuman lebih lanjut terkait ini dalam waktu dekat
      Hal mendasar yang perlu dipahami adalah Fly Volumes bukan penyimpanan SAN, dan juga bukan penyimpanan yang secara inheren andal seperti S3
      Di dalam Fly Machines, ia terlihat sebagai filesystem ext4 biasa, dan jika membutuhkan keandalan, durabilitas, serta replikasi, itu harus disediakan di lapisan aplikasi
      Fly Postgres berjalan sebagai klaster read replica, dan bila perlu replica mana pun dapat mengambil alih peran write leader, jadi pendekatan itu sesuai
      Inilah juga alasan kami menampilkan peringatan merah besar di konsol jika Anda mencoba membuat klaster Postgres single-node
      Dalam beberapa kuartal ke depan, kemungkinan kami akan menghadirkan pilihan baru pada spektrum keandalan dan performa, tetapi tampaknya bukan dalam bentuk mengoperasikan sendiri drive SAN yang hanya mengekspos block device seperti iSCSI

  • Saya benar-benar tidak suka model harga kedua perusahaan ini
    Di satu ujung ada Supabase, dengan paket bertingkat ala platform developer seperti Vercel yang membuat Anda membayar lebih dari pemakaian sebenarnya
    Di ujung lain ada Fly, dengan harga yang terlalu granular per detik, per memori, per CPU seperti Lambda, sehingga kemungkinan Anda malah membayar terlalu sedikit lalu mengalami penurunan performa
    Ada hal seperti Cloudflare Workers; saya tidak begitu paham kenapa harus memilih salah satu dari keduanya. Kenapa masih ingin mengkhawatirkan skalabilitas?

    • Cloudflare Workers tidak punya opsi Postgres. Paling jauh ada Hyperdrive untuk terhubung ke Postgres yang di-host di tempat lain, dan itu pun pada dasarnya connection pooler sehingga menambah batasan
      Sepertinya kecil kemungkinan Cloudflare menyediakan Postgres sungguhan. Filosofi Cloudflare adalah apa pun yang Anda deploy akan didistribusikan ke seluruh dunia, sedangkan database relasional memaksa satu server menjadi sumber kebenaran
      Tentu saja saya akan senang kalau terbukti salah
    • Coba jalankan container Docker arbitrer yang Anda butuhkan di Cloudflare Workers, maka Anda akan tahu alasannya
      Harga bulanan Fly cukup intuitif dan sama sekali tidak mirip Lambda. Justru di antara keduanya, model harga Cloudflare Workers lebih dekat ke Lambda
    • Pada akhirnya karena ekosistem PostgreSQL, pengalaman developer, dan berbagai fitur tambahan