Sering ada yang nanya begini setelah baca artikel saya soal Zero Server Cost pakai Google Apps Script: "kalau gitu semua sistem yang kamu bikin pasti pakai Google Sheets dong?" Jawabannya tidak. Dari beberapa sistem yang saya bangun — baik yang jadi showcase publik maupun yang bekerja diam-diam di balik layar — masing-masing pakai arsitektur database dan hosting yang berbeda. Itu pilihan sadar, bukan karena tidak konsisten.
Assets DEMO — Google Sheets & Google Apps Script
Untuk sistem manajemen aset seperti Assets DEMO, kebutuhan utamanya adalah biaya Rp0 per bulan dan kepemilikan data 100% di tangan klien — bukan tersimpan di server pihak ketiga yang harus dipercaya begitu saja. Volume transaksinya pun tidak ekstrem: pencatatan aset, mutasi, depresiasi bulanan — bukan ribuan transaksi bersamaan tiap detik. Google Sheets sebagai database dan Apps Script sebagai logic engine pas untuk profil kebutuhan ini.
B-Games — Supabase (PostgreSQL)
B-Games itu cerita yang beda sama sekali. Ada relasi data yang jauh lebih kompleks — profil pengguna, daftar pertemanan, dompet koin, riwayat pertandingan, leaderboard global yang harus di-query dan diurutkan cepat. Ini jenis kebutuhan yang Google Sheets tidak akan sanggup tangani dengan baik begitu datanya membesar — query relasional semacam itu memang wilayahnya database seperti PostgreSQL.
Supabase dipilih karena memberi database PostgreSQL penuh plus autentikasi dan realtime subscription siap pakai, tanpa harus mengelola server database sendiri dari nol.
Mesin RAB di Balik Zannah — Cloudflare Edge & Turso
Satu hal yang perlu diluruskan dulu: ini bukan "proyek showcase" seperti dua yang di atas. Tidak ada halaman demo terpisah, tidak muncul di halaman proyek, dan namanya tidak pernah disebut eksplisit ke pengunjung — dia cuma mesin yang dipanggil Zannah di belakang layar saat pengunjung minta dibuatkan RAB. Tapi keputusan arsitekturnya tetap relevan dibahas, karena pertimbangannya beda lagi dari dua sistem di atas.
Mesin ini dipakai dari mana saja tanpa tahu kapan trafiknya datang, jadi latensi akses harus tetap rendah dari kota mana pun. Cloudflare dipilih karena jaringannya tersebar di ratusan pusat data global, dan Turso sebagai database terdistribusi memastikan data proposal dan status pembayaran tersinkron cepat tanpa satu titik kegagalan tunggal.
Website Portofolio Utama — Vercel
Untuk situs utama sendiri, trafiknya tidak menentu — bisa sepi, bisa melonjak kalau ada yang membagikan link ke grup atau media sosial. Vercel dengan arsitektur serverless-nya cocok untuk pola ini: fungsi backend cuma aktif dan dikenai biaya saat ada permintaan, bukan biaya flat bulanan yang tetap jalan meski trafiknya nol.
Pertanyaan yang Sebenarnya Menentukan Pilihan
Kalau ditarik pola umumnya, ada empat pertanyaan yang saya ajukan sebelum menentukan arsitektur untuk sistem apa pun (termasuk punya klien): seberapa kompleks relasi datanya, seberapa besar toleransi biaya bulanan, siapa yang harus punya kendali penuh atas data, dan seberapa penting sinkronisasi real-time antar banyak pengguna sekaligus. Jawaban dari empat pertanyaan itu yang menentukan arsitekturnya — bukan sekadar ikut tren teknologi yang lagi ramai dibicarakan.
Kalau kamu sedang bingung menentukan arsitektur yang pas untuk kebutuhan bisnismu, ini bisa jadi bahan diskusi awal yang gratis, tanpa kewajiban order.