Supabase atau Firebase: model data menentukan biaya

Pilih Supabase jika inti aplikasi berupa data yang saling berelasi dan perlu digabung dalam kueri. Pilih Firebase Cloud Firestore jika data lebih alami diakses sebagai dokumen dan klien perlu menerima perubahan secara langsung. Bahkan sebelum trafik besar, rancangan layar dan cara data disimpan sudah menentukan berapa banyak operasi, kapasitas, serta transfer data yang terpakai.

Perbandingan ini menempatkan PostgreSQL di Supabase dan Cloud Firestore Standard di Firebase sebagai pilihan utama. Firebase juga memiliki SQL Connect berbasis PostgreSQL, sehingga keputusan memakai Firebase tidak selalu berarti memakai basis data dokumen. Untuk memilih, perhatikan relasi data, jumlah pembacaan per layar, penerima setiap perubahan, berkas yang dikirim, dan pekerjaan yang diperlukan bila model data kelak diubah.

Dari model data ke satuan tagihan

Menurut rincian harga Supabase, paket Pro mulai US$25 per bulan dengan proyek pertama termasuk, kuota disk basis data 8 GB per proyek, penyimpanan berkas 100 GB, 100.000 pengguna aktif bulanan, serta masing-masing 250 GB egress biasa dan egress dari cache. Permintaan API tidak dihitung satu per satu dalam daftar harga tersebut, tetapi ukuran komputasi, proyek tambahan, dan pemakaian di atas kuota tetap dapat memengaruhi biaya. Spend cap paket Pro aktif secara bawaan; batas itu perlu dipahami bersama dampaknya terhadap layanan ketika kuota habis.

Pada tabel harga Firebase, Spark adalah paket tanpa biaya dan Blaze memakai skema bayar sesuai pemakaian; Cloud Firestore Standard menyediakan kuota 50.000 pembacaan, 20.000 penulisan, dan 20.000 penghapusan dokumen per hari, ditambah 1 GiB data tersimpan dan 10 GiB transfer keluar per bulan. Tarif setelah kuota bergantung pada lokasi basis data. Authentication, Cloud Storage, dan SQL Connect memiliki satuan biaya tersendiri; SQL Connect juga melibatkan Cloud SQL for PostgreSQL setelah masa uji coba yang berlaku.

Karena satu paket mengenakan biaya awal dan paket lain menghitung operasi, membandingkan harga langganan dengan kuota gratis saja tidak memberi jawaban. Satu halaman yang mengambil banyak dokumen dapat mendekati batas harian Firestore meski jumlah pengunjung kecil. Sebaliknya, kueri relasional di Supabase tetap memakai komputasi dan menghasilkan egress meski tidak menghasilkan tagihan per dokumen yang dibaca.

CRUD relasional: jumlah operasi mengikuti bentuk pesanan

Bayangkan aplikasi pesanan dengan pelanggan, pesanan, dan baris barang sebagai entitas terpisah. Dalam contoh hipotetis, ada 300 pesanan sehari dan setiap pesanan menulis satu dokumen pesanan serta tiga dokumen baris barang di Firestore. Itu berarti 1.200 penulisan dokumen sehari, sebelum pembaruan stok, perubahan status, atau data lain ikut dihitung.

Di PostgreSQL, pelanggan, pesanan, dan baris barang dapat dihubungkan melalui kunci dan diambil dengan kueri relasional. Di Firestore, dokumen dan kueri perlu dirancang untuk tampilan yang akan digunakan aplikasi. Menyalin nama barang ke dokumen pesanan, misalnya, dapat mengurangi pembacaan dokumen barang saat riwayat pesanan dibuka, tetapi perubahan nama barang kemudian menimbulkan pertanyaan: apakah salinan lama harus ikut diperbarui?

Untuk aplikasi CRUD dengan banyak hubungan antardata, Supabase memberi titik awal yang jelas untuk menilai kueri dan perubahan skema. Jika ekosistem Firebase tetap dibutuhkan bersama basis data relasional, SQL Connect merupakan pilihan lain, dengan pola biaya yang berbeda dari Firestore. Perbedaan itu penting sebelum kode klien, aturan akses, dan struktur data terlanjur mengikuti bentuk dokumen tertentu.

Percakapan waktu nyata: pesan dikalikan penerima

Dalam percakapan, jumlah pesan yang ditulis tidak sama dengan jumlah pembacaan yang ditagih. Aturan penagihan Cloud Firestore menghitung pembacaan saat dokumen masuk atau diperbarui dalam hasil listener; penyambungan kembali dapat dihitung seperti kueri baru, bergantung pada persistensi luring. Kueri tertentu juga dikenai pembacaan entri indeks, sedangkan aturan keamanan yang membaca dokumen lain dapat menambah pembacaan.

Dalam contoh hipotetis, 100 anggota masing-masing membuka ruang yang memuat 30 pesan awal. Pembukaan itu menghasilkan 3.000 pembacaan dokumen. Jika kemudian 200 pesan baru diterima oleh seluruh anggota yang tetap terhubung, perubahan tersebut menambah sekitar 20.000 pembacaan; total ilustrasinya sekitar 23.000 pembacaan dan 200 penulisan, sebelum operasi lain dihitung. Angka nyata berubah ketika anggota keluar, kueri dibatasi, atau klien tersambung kembali.

Menurut penghitungan pesan Realtime Supabase, setiap perubahan basis data dihitung sebagai satu pesan bagi tiap klien yang mendengarkannya; kuota pesan bulanan paket Free adalah 2 juta dan Pro 5 juta. Dengan asumsi yang sama, 200 perubahan yang diterima 100 klien menghasilkan sekitar 20.000 pesan Realtime, di samping pemakaian basis data dan transfer data. Firestore menghitung pembacaan terhadap kuota harian, sedangkan Supabase menghitung pesan Realtime terhadap kuota bulanan; kedua angka itu tidak dapat dibandingkan langsung tanpa pola penggunaan sepanjang hari dan bulan.

Katalog: hari ramai lebih penting daripada rata-rata

Katalog dapat memiliki sedikit penulisan tetapi banyak pembacaan berulang. Dalam contoh hipotetis, satu halaman menampilkan 30 dokumen produk dan dibuka oleh 2.000 pengunjung pada hari promosi. Jika setiap pembukaan mengambil seluruh dokumen itu dari Firestore, hasilnya 60.000 pembacaan pada hari tersebut, sebelum halaman lanjutan, pencarian, atau penyegaran dihitung. Rata-rata kunjungan bulanan akan menyembunyikan puncak harian seperti ini.

Di Supabase, pengambilan katalog tidak dihitung sebagai pembacaan dokumen per pengunjung, tetapi kuerinya memakai komputasi dan responsnya memakai egress. Gambar produk menambah satuan lain di kedua platform: ruang untuk menyimpan berkas berbeda dari transfer saat berkas itu diunduh. Karena itu, halaman katalog bergambar perlu dipisahkan menjadi data produk, berkas yang tersimpan, dan data yang terkirim kepada pengunjung.

Membatasi hasil per halaman mengubah jumlah dokumen yang dibaca sekaligus ukuran respons yang dikirim. Cache dapat mengubah pola pengiriman aset yang jarang berubah, tetapi tidak membuat semua permintaan basis data otomatis hilang. Untuk katalog dengan trafik tidak merata, rancangan halaman dan perilaku cache bisa lebih menentukan daripada jumlah pengguna terdaftar.

Batas pengeluaran dan pekerjaan migrasi

Pada Blaze, peringatan anggaran memberi tahu saat biaya mencapai ambang tertentu tanpa menghentikan layanan. Aturan spend cap Firebase menyebut fitur batas pengeluaran yang masih berstatus pratinjau hanya tersedia untuk layanan tertentu, bukan Cloud Firestore, dan penerapannya dapat terlambat karena pelaporan pemakaian tidak seketika. Karena itu, lonjakan pembacaan Firestore perlu dinilai melalui pola kueri dan pengawasan biaya, bukan diasumsikan berhenti otomatis pada nilai anggaran.

Biaya pindah juga mengikuti model yang dipilih sejak awal. Pemindahan aplikasi Supabase tetap mencakup data, aturan akses, autentikasi, berkas, dan fitur waktu nyata. Pemindahan dari Firestore ke model relasional menambah pekerjaan memetakan dokumen menjadi tabel, menulis ulang kueri, serta menyesuaikan kode klien yang bergantung pada listener. Untuk keputusan awal, gambarkan layar yang paling sering dibuka dan proses penulisan yang paling penting; jumlah catatan yang disentuh, penerima perubahan, dan ukuran hasilnya menunjukkan satuan tagihan yang akan tumbuh bersama penggunaan.