Kapan Google Sheets Cukup Jadi Database Webapp, dan Kapan Harus Pindah

Google Sheets yang dijadikan backend webapp lewat Apps Script itu genuinely game changing. Gratis, klien sudah familier sama tampilannya, dan bisa jalan dalam hitungan hari, bukan minggu. Hampir semua sistem yang aku bangun untuk klien kecil-menengah pakai pola ini.

Tapi Sheets tetap punya batas, dan batas itu bukan cuma soal "kapan penuh". Di artikel ini aku bahas batas yang sebenarnya, masalah yang lebih sering muncul duluan sebelum batas itu kena, dan cara aku kasih tahu klien soal batas amannya dari awal, sebelum sistemnya dibangun.

Batas Google Sheets yang jarang dibaca sampai kena

Beberapa batas ini sifatnya keras, nggak bisa dibeli atau di-upgrade:

• 20 juta sel per spreadsheet. Ini angka baru, baru saja digandakan dari 10 juta oleh Google, mulai digulirkan 10 September 2026. Batas ini berlaku untuk seluruh file, bukan per tab, dan sel kosong ikut dihitung.
• 18.278 kolom maksimal (sampai kolom ZZZ) per sheet.
• 6 menit per eksekusi Apps Script, sama untuk akun gratis maupun Google Workspace, menurut dokumentasi resmi Apps Script. Batas 30 menit yang dulu sering disebut untuk akun Workspace sudah nggak berlaku lagi.
• Jatah trigger per hari: 90 menit untuk akun gratis, 6 jam untuk Google Workspace.
• UrlFetch (buat manggil API luar dari Apps Script): 20.000 panggilan per hari akun gratis, 100.000 untuk Workspace.

Batas sel per spreadsheet, naik dari 10 juta mulai September 2026

20 juta

Batas eksekusi Apps Script per run, sama untuk semua akun

6 menit

Jatah trigger per hari untuk akun gratis, 6 jam untuk Workspace

90 menit

Angka sel itu kelihatan besar, tapi yang penting justru berapa banyak baris yang kamu dapat, dan itu tergantung berapa kolom yang dipakai:

Perkiraan jumlah baris maksimal, tergantung jumlah kolom(baris)

• 5 kolom4 juta
• 10 kolom2 juta
• 20 kolom1 juta
• 26 kolom±769 ribu

Masalah yang lebih sering muncul duluan: konflik akses bersamaan

Dari pengalaman, proyek jarang gagal karena kehabisan sel. Yang lebih sering bikin masalah adalah beberapa orang atau proses mengakses sheet yang sama di waktu yang (nyaris) bersamaan.

Google Sheets sendiri bisa dibuka dan diketik banyak orang sekaligus di level UI. Masalahnya ada di level Apps Script: kalau dua eksekusi script sama-sama baca posisi baris terakhir lalu menulis di baris berikutnya, dan itu terjadi hampir bersamaan, hasilnya bisa dua baris ketimpa jadi satu, atau ID yang harusnya unik malah dobel.

LockService di Apps Script bisa mengunci proses ini supaya berjalan satu-satu, tapi itu artinya permintaan yang datang bersamaan jadi antre. Kalau nggak dipasang dengan benar, bukannya error yang muncul, datanya yang diam-diam salah tanpa ketahuan.

Nggak semua project butuh database yang lebih "canggih"

Pindah ke MySQL atau Firebase bukan cuma soal teknis, ada biaya dan kerumitan baru: butuh server atau layanan terkelola, kode backend tambahan, dan klien nggak bisa lagi buka spreadsheet buat lihat datanya langsung.

Sheets biasanya masih cukup kalau:

• Penulisan data nggak terlalu sering terjadi bersamaan dalam hitungan detik yang sama (misalnya form yang diisi beberapa kali sehari, bukan ratusan kali semenit).
• Volume datanya jauh di bawah batas sel, dengan ruang tumbuh yang jelas.
• Klien justru ingin bisa buka dan cek datanya langsung tanpa panel admin.
• Sistemnya nggak butuh sinkronisasi real-time ke banyak layar sekaligus.

Waktunya dipertimbangkan pindah kalau:

• Mulai sering dapat laporan data "ketimpa" atau hilang.
• Script mulai kena timeout 6 menit karena datanya makin besar.
• Butuh relasi antar data yang kompleks (join banyak tabel), bukan cuma baris-baris independen.
• Butuh tampilan yang update sendiri secara real-time di banyak perangkat sekaligus.

Kalau sudah waktunya pindah

Dua arah yang paling umum aku pakai:

• MySQL atau PostgreSQL: database relasional biasa, jalan di VPS sendiri (aku bahas spek dan biayanya di VPS untuk AI Itu Gimana dan Bisa Apa Aja?). Cocok kalau datanya banyak relasi antar tabel dan kamu mau kendali penuh.
• Firebase/Firestore: layanan terkelola dari Google, kuat di sinkronisasi real-time ke banyak user sekaligus, nggak perlu urus server sendiri. Cocok buat aplikasi yang butuh beberapa orang melihat perubahan data secara langsung, tanpa refresh manual.

Kasih tahu klien dari awal

Bagian ini yang sering kelewat: klien perlu tahu batas amannya sejak sistemnya masih di tahap rencana, bukan pas sistemnya mulai lambat. Sebelum mulai bangun di atas Sheets, aku selalu samakan tiga hal dengan klien:

1. Perkiraan berapa user yang akan mengakses bersamaan, dan seberapa sering mereka menulis data di waktu yang sama.
2. Perkiraan pertumbuhan data setahun ke depan, supaya ada jarak aman ke batas sel.
3. Apa yang terjadi kalau nanti harus pindah database, jadi itu bukan kejutan.

Penutup

Google Sheets sebagai database itu bukan jalan pintas yang harus buru-buru ditinggalkan, tapi juga bukan solusi yang cocok untuk semua skala selamanya. Yang penting adalah tahu batasnya dari awal, bukan nemuin batas itu pas sistemnya sudah dipakai serius sama klien.

Kalau kamu lagi menimbang mau pakai Sheets atau langsung ke database yang lebih besar, cerita aja soal kebutuhan sistemnya, nanti dihitung bareng skala yang paling pas.