Tech Comparison Firebase vs Supabase: Benchmarking Query Speed pada 1 Juta Rows Data Relasional

Perbandingan Performa Firebase vs Supabase: Analisis Latensi Query dan Arsitektur Database Skala Besar 

Depok, BisnisGo.id - Evolusi arsitektur aplikasi modern telah mengalami pergeseran seismik dari pengelolaan infrastruktur manual menuju adopsi model Serverless dan Backend-as-a-Service (BaaS). Dalam dekade terakhir, janji untuk melepaskan beban manajemen server dan pemeliharaan database telah mendorong ribuan tim teknis mengadopsi platform BaaS sebagai tulang punggung teknologi mereka. Di puncak hierarki ini, terdapat dua entitas dominan yang mewakili filosofi data yang berlawanan: Firebase, platform milik Google yang mengusung paradigma NoSQL melalui Cloud Firestore, dan Supabase, penantang open-source yang membawa kekuatan RDBMS PostgreSQL ke ekosistem cloud-native.

Laporan riset ini menyajikan analisis teknis mendalam mengenai kinerja kedua platform tersebut, dengan fokus spesifik pada satu metrik kritis: Query Speed pada dataset relasional berukuran 1 Juta baris. Pemilihan angka 1 juta baris bukanlah tanpa alasan; ini adalah ambang batas psikologis dan teknis di mana keputusan arsitektural awal mulai menunjukkan dampak nyatanya, baik berupa degradasi performa yang melumpuhkan atau lonjakan biaya operasional yang eksponensial. (Source: Tech Comparison Firebase vs Supabase).

1. Mitos Industri Menyederhanakan Realitas Teknis di Lapangan

Narasi industri yang berkembang saat ini sering kali menyederhanakan perbandingan menjadi dikotomi dangkal: "Firebase cepat untuk real-time tetapi mahal untuk read, sedangkan Supabase kuat di SQL tetapi kompleks untuk diatur". Namun, realitas teknis di lapangan jauh lebih bernuansa. Ketika dataset tumbuh melampaui ratusan ribu entitas dengan hubungan yang saling terkait (relasional), keterbatasan fundamental dari model dokumen NoSQL mulai berbenturan keras dengan kebutuhan bisnis akan kueri yang kompleks, agregasi data, dan integritas referensial.

Kami akan membedah anatomi performa dari Complex Joins, Aggregation, dan Real-time Subscriptions. Kita akan mengeksplorasi bagaimana Firestore menangani—atau gagal menangani—gabungan data rumit melalui solusi client-side yang memboroskan bandwidth, dan membandingkannya dengan efisiensi eksekusi native query plan pada mesin PostgreSQL yang digunakan Supabase. Analisis ini bertujuan memberikan panduan arsitektural definitif bagi para CTO dan Lead Developer yang berada di persimpangan jalan pemilihan teknologi.

2. Bedah Arsitektur Firestore Mengungkap Pedang Bermata Dua "Index-Everything"

Untuk memahami implikasi performa pada skala 1 juta baris, kita tidak bisa hanya melihat angka latensi di permukaan, melainkan harus membedah "mesin" penggeraknya. Cloud Firestore adalah database NoSQL berbasis dokumen yang dirancang untuk skalabilitas horizontal otomatis. Fitur teknis paling menonjol dari Firestore adalah pendekatan "Index-Everything".

Secara default, Firestore secara otomatis membuat indeks untuk setiap field dalam sebuah dokumen. Strategi ini memiliki implikasi teknis yang masif:

• Keunggulan Skalabilitas Baca: Kinerja kueri di Firestore berskala sebanding dengan ukuran result set (jumlah hasil yang dikembalikan), bukan ukuran total dataset. Mencari 10 pengguna dari koleksi berisi 100 pengguna membutuhkan waktu yang sama dengan mencari 10 pengguna dari koleksi berisi 100 juta pengguna. Firestore tidak pernah melakukan Full Table Scan.

• Kelemahan Penulisan: Konsekuensinya, setiap operasi penulisan (write) menjadi lebih berat karena database harus memperbarui entri indeks untuk setiap field yang berubah.

• Keterbatasan Relasional: Firestore tidak memiliki konsep Foreign Key atau Native JOIN di tingkat server. Data tersebar di berbagai shard fisik. Menggabungkan data dari dua koleksi (misalnya Users dan Orders) di sisi server menjadi sangat sulit secara komputasi, sehingga beban tersebut dilimpahkan sepenuhnya ke aplikasi klien.

Editor's Note: Algoritma Zigzag Merge Join

Ketika aplikasi memerlukan filter majemuk (misalnya WHERE city == 'Jakarta' AND age > 25), Firestore tidak memindai dokumen. Ia menggunakan algoritma Zigzag Merge Join. Firestore melompat bolak-balik antara indeks city dan indeks age, mencari persimpangan ID dokumen. Ini efisien untuk filter, namun gagal total ketika melibatkan agregasi lintas koleksi.

3. Supabase Mengandalkan Kekuatan Query Planner PostgreSQL

Supabase mengambil pendekatan fundamental yang berbeda dengan membungkus PostgreSQL ke dalam format yang mudah dikonsumsi (RESTful API). Keunggulan absolut PostgreSQL pada dataset relasional terletak pada Query Planner.

Ketika permintaan masuk untuk menggabungkan tabel Users (1 juta baris) dan Orders (5 juta baris), PostgreSQL menganalisis statistik distribusi data dan memilih algoritma join terbaik—apakah itu Nested Loop Join (efisien untuk data kecil), Hash Join (cepat untuk data besar tak terurut), atau Merge Join. Mesin database melakukan penggabungan ini di memori server dan hanya mengirimkan hasil akhir yang bersih ke klien.

Berikut adalah tabel perbandingan arsitektur yang mendasari performa kedua platform:

4. Metodologi Benchmark Mensimulasikan Beban Nyata Aplikasi E-Commerce

Untuk memberikan analisis yang objektif, riset ini mendefinisikan skenario pengujian standar yang mencerminkan kasus penggunaan dunia nyata seperti platform E-Commerce atau SaaS.

Spesifikasi Dataset:

• Entitas Utama (Users): 1.000.000 baris/dokumen. Struktur mencakup ID (UUID), Name, Email, Status, dan Metadata JSON.

• Entitas Terkait (Orders): 5.000.000 baris/dokumen. Rasio rata-rata 5 order per user. Struktur mencakup ID, UserID (Foreign Key), Amount, dan Status.

• Entitas Penghubung (OrderItems): 15.000.000 baris (khusus SQL) atau embedded array di NoSQL.

Lingkungan Pengujian:

Pengujian dilakukan menggunakan klien Node.js yang berjalan di region AWS yang sama dengan server Supabase untuk meminimalkan latensi jaringan murni, serta koneksi internet standar ke endpoint Google Cloud untuk Firestore. Konfigurasi Supabase menggunakan Instance Pro standar (2 vCPU, 8GB RAM), sedangkan Firestore berjalan pada mode Native lokasi multi-region.

Analisis Performa Complex Joins: Firestore Client-Side vs Supabase Native SQL pada Skala Besar 

Setelah memahami perbedaan fundamental arsitektur pada Bagian 1, kita memasuki medan pertempuran utama: Complex Joins. Di sinilah perbedaan antara NoSQL dan SQL menjadi sangat nyata dan menyakitkan bagi performa aplikasi.

Skenario bisnis yang kita uji sangat umum: "Tampilkan daftar 50 pesanan terbaru, lengkap dengan Nama Pengguna dan Email pemesan."

Di atas kertas, ini tugas sepele. Namun, pada dataset 1 juta baris, cara Firestore dan Supabase menangani tugas ini ibarat membandingkan pengiriman paket menggunakan ribuan kurir sepeda motor (Firestore) melawan satu kereta kargo cepat (Supabase). (Source: Tech Comparison Firebase vs Supabase).

1. Pendekatan Firebase: Mimpi Buruk "N+1" dan Air Terjun Latensi

Karena Firestore tidak memiliki kemampuan JOIN di sisi server, pengembang dihadapkan pada keterbatasan fisik arsitektur. Untuk menggabungkan data Orders dan Users, beban komputasi dilimpahkan ke aplikasi klien (Client-side Join). Ini memicu fenomena yang dikenal sebagai Masalah N+1.

Prosesnya menciptakan efek waterfall (air terjun) pada jaringan:

1. Query Pertama: Ambil 50 dokumen dari koleksi Orders. (Biaya: 1 Round-Trip Network).

2. Pemrosesan Lokal: Aplikasi menerima 50 objek JSON, lalu mengekstrak 50 user_id unik.

3. Query Kedua (Lookup Users): Di sinilah bencana terjadi. Firestore membatasi klausa IN maksimal 10 atau 30 elemen (tergantung SDK). Pengembang terpaksa memecah request atau melakukan looping.

Kode Implementasi Firestore (Inefisien)

// Langkah 1: Ambil 50 Order (1 Request)
const ordersSnapshot = await db.collection('orders')
  .orderBy('created_at', 'desc')
  .limit(50)
  .get();

const orders = ordersSnapshot.docs.map(doc => doc.data());

// Langkah 2: Ambil User untuk setiap Order (N Request)
// Masalah: Menciptakan 50 request paralel atau batch request yang berat
const populatedOrders = await Promise.all(orders.map(async (order) => {
  // Ini memicu round-trip jaringan tambahan untuk setiap user!
  const userSnapshot = await db.collection('users').doc(order.user_id).get();
  return {
    ...order,
    user: userSnapshot.data()
  };
}));

Analisis Dampak:

• Latensi Jaringan: Jika latensi satu kali jalan (RTT) adalah 50ms, operasi ini minimal memakan waktu 50ms (Orders) + 50ms (Users) + Overhead Processing. Pada koneksi seluler 4G yang tidak stabil, waktu tunggu pengguna bisa membengkak menjadi 400ms - 600ms hanya untuk satu halaman daftar.

• Biaya Ganda: Kamu dikenakan biaya baca untuk 50 dokumen Order + 50 dokumen User = 100 Operasi Baca.

2. Jalan Pintas yang Berbahaya: Jebakan Denormalisasi

Untuk menghindari masalah performa di atas, arsitek Firestore sering memilih jalan pintas: Denormalisasi. Saat dokumen Order dibuat, data user_name dan user_email disalin dan disimpan langsung di dalam dokumen Order.

• Keuntungan: Read menjadi sangat cepat (1 query tunggal).

• Kelemahan Fatal: Integritas data menjadi mimpi buruk. Jika seorang User mengubah emailnya, aplikasi harus menjalankan Cloud Function di latar belakang untuk mencari dan memperbarui ribuan dokumen Order historis milik user tersebut. Pada skala 1 juta user dan 5 juta order, operasi fan-out write ini sangat mahal, lambat, dan rawan kesalahan (data inconsistency). (Source: Tech Comparison Firebase vs Supabase).

3. Pendekatan Supabase: Efisiensi SQL Native

Supabase menyelesaikan masalah yang sama dengan pendekatan yang jauh lebih elegan. Tidak ada looping di klien, tidak ada multiple requests. Solusinya hanyalah satu blok instruksi SQL yang dieksekusi di server.

Kode Implementasi Supabase (Efisien):

-- Satu request ke server, data kembali sudah tergabung rapi
SELECT
  orders.id,
  orders.total,
  orders.created_at,
  users.name,    -- Data dari tabel User
  users.email
FROM orders
JOIN users ON orders.user_id = users.id -- Native Server-side Join
ORDER BY orders.created_at DESC
LIMIT 50;

Mekanisme Eksekusi Server: Ketika kueri ini sampai ke Supabase, engine PostgreSQL melakukan hal berikut:

1. Scanning Index: Menggunakan indeks pada orders.created_at untuk mengambil 50 baris teratas secara instan.

2. Join Execution: Mengambil 50 user_id dari hasil tersebut dan melakukan Index Scan pada Primary Key tabel Users. Karena indeks B-Tree tersimpan di memori (RAM), pencarian 50 kunci ini terjadi dalam hitungan mikrodertik.

3. Transport: Satu paket hasil final dikirim ke klien. Hemat bandwidth, hemat kuota.

4. Vonis Performa: Supabase Menang Telak di Data Relasional

Dalam benchmark independen dengan dataset 1 juta baris, Supabase secara konsisten mencatat waktu ~80-90ms untuk operasi join kompleks ini. Sebaliknya, pendekatan client-side Firestore sering kali melampaui 250ms - 500ms tergantung pada kondisi jaringan klien.

Selain itu, efisiensi bandwidth Supabase jauh lebih unggul. Tidak ada data perantara (intermediate data) seperti daftar ID yang harus dikirim bolak-balik lewat jaringan. Payload respons sangat optimal, hanya berisi data yang diminta.

Editor's Note: Kasus Many-to-Many Tantangan menjadi lebih ekstrem pada relasi Many-to-Many (misal: Siswa dan Kelas). Firestore memaksa penggunaan array yang dibatasi ukuran dokumen 1MB atau sub-koleksi yang rumit di-query. Supabase menangani ini dengan tabel junction standar (student_classes) yang sangat ringan dan cepat.

Analisis Biaya dan Real-time: Firebase vs Supabase pada Skala Enterprise (TCO Comparison)

Dalam dua bagian sebelumnya, kita telah melihat bagaimana Supabase unggul dalam Query Speed relasional dan efisiensi bandwidth. Namun, performa teknis hanyalah separuh dari persamaan bisnis. Separuh lainnya adalah Ekonomi Skala.

Salah satu mitos paling berbahaya di ekosistem startup adalah anggapan bahwa "Firebase itu murah karena ada Free Tier". Realitasnya, model bisnis Firebase dirancang untuk memajaki pertumbuhan kamu. Laporan ini akan membedah model biaya (Total Cost of Ownership) pada skala 1 juta baris data, serta membandingkan kemampuan Real-time kedua platform. (Source: Tech Comparison Firebase vs Supabase).

1. Agregasi data: Menghitung biaya "Pengetahuan"

Salah satu operasi paling mendasar dalam manajemen data adalah mengetahui "Berapa banyak?". Pertanyaan sederhana seperti "Berapa jumlah pengguna aktif hari ini?" memicu mekanisme biaya yang sangat berbeda.

Firebase (Firestore): Biaya Tersembunyi Agregasi

Secara historis, untuk menghitung jumlah dokumen, kamu harus mengunduh semua dokumen tersebut (mahal & lambat). Kini, Firestore memiliki fitur count(). Apakah gratis? Tidak.

• Mekanisme: Firestore memindai indeks, bukan dokumen.

• Biaya: Kamu dikenakan biaya 1 operasi baca dokumen untuk setiap 1.000 entri indeks yang dipindai.

• Simulasi: Menghitung 1 juta pengguna = 1.000 operasi baca. Jika kamu punya dashboard admin yang me-refresh angka ini setiap 5 menit selama 24 jam, kamu membayar 288.000 operasi baca per hari hanya untuk menampilkan satu angka.

Supabase (PostgreSQL): Fleksibilitas Statistik

PostgreSQL menawarkan spektrum opsi. Untuk kebutuhan dashboard yang tidak memerlukan presisi atomik (misal: "Sekitar 1 Juta User"), Supabase memungkinkan pengambilan metadata statistik sistem yang Gratis dan Instan (< 1ms)

-- Supabase: Estimasi Instan (O(1)) - Gratis & Cepat
-- Mengambil metadata statistik sistem, tidak perlu scan tabel.
SELECT reltuples AS estimate 
FROM pg_class 
WHERE relname = 'users';

2. Duel Real-time: Skalabilitas Masif vs Fleksibilitas Broadcast

Fitur Real-time adalah nilai jual utama Firebase. Namun, Supabase mengejar dengan pendekatan Change Data Capture (CDC) berbasis Write-Ahead Log (WAL).

• Firestore (Pemenang Konkurensi): Dirancang untuk menangani koneksi konkuren dalam jumlah raksasa (hingga 1 juta koneksi simultan). Infrastruktur Google secara otomatis melakukan sharding. Jika kamu membuat aplikasi Live Voting nasional atau Chat masif, Firestore lebih teruji menangani "tsunami" koneksi.

• Supabase (Pemenang Fleksibilitas): Menggunakan server Elixir/Phoenix. Fitur unggulannya adalah Broadcast, yang memungkinkan pengiriman pesan instan (seperti kursor mouse di Figma atau posisi game) tanpa menyentuh database (tanpa biaya simpan disk). Namun, throughput perubahan database (CDC) memiliki batas fisik karena sifat single-threaded dari replikasi WAL untuk menjamin urutan transaksi.

3. Analisis Biaya Total (TCO): The Firebase Cliff

Perbedaan filosofi biaya adalah penentu utama bagi CFO.

• Model Firebase (Pay-as-you-go): Kamu membayar per tindakan. Ini murah di awal, tapi berbahaya saat skala membesar.

  • Bahaya: Jika ada bug kode yang menyebabkan looping request, atau serangan DDoS yang memicu pencarian berulang, tagihan bisa melonjak dari $50 menjadi $5.000 dalam satu malam. Tidak ada fitur "Hard Stop" bawaan untuk mencegah ini. Ini disebut "The Firebase Cliff".

• Model Supabase (Provisioned Capacity): Kamu menyewa kapasitas komputer (mirip sewa server VPS).

  • Keamanan Biaya: Paket Pro ($25/bulan) memberikan kapasitas tertentu. Kamu bisa melakukan 3 juta atau 300 juta reads tanpa biaya tambahan, selama CPU kuat. Jika trafik melonjak tajam, database mungkin melambat, tapi tagihan kamu tetap $25. Ini memberikan prediksi biaya (fixed cost) yang disukai perusahaan.

Tabel Simulasi Biaya (Estimasi Bulanan):

4. Kesimpulan Strategis: Kapan Harus Migrasi?

Berdasarkan rangkaian analisis teknis deep dive ini, berikut adalah vonis akhirnya:

1. Pilih Supabase (PostgreSQL) Jika:

   • Data kamu saling terkait (relasional) dan membutuhkan integritas referensial.

   • Aplikasi kamu adalah B2B SaaS, CRM, ERP, atau E-Commerce inventaris besar.

   • Kamu membutuhkan kueri analitik kompleks (Group By, Join, Aggregation).

   • Kamu menginginkan prediksi biaya infrastruktur yang stabil (Flat Rate).

2. Pilih Firebase (Firestore) Jika:

   • Aplikasi kamu berdiri sendiri dengan data dokumen independen (Content Feed).

   • Kebutuhan utamanya adalah Offline-First di perangkat mobile (sinkronisasi otomatis saat sinyal hilang).

   • Kamu membutuhkan konkurensi ekstrem (1 juta+ user online bersamaan) tanpa mau mengurus manajemen kapasitas server sedikitpun.

Pada akhirnya, di era data berskala besar, disiplin skema SQL dan kekuatan optimizer database relasional di Supabase sering kali membuktikan dirinya sebagai investasi yang lebih berkelanjutan daripada fleksibilitas awal yang ditawarkan oleh NoSQL Firebase. (Source: Tech Comparison Firebase vs Supabase).