Kapan otomasi butuh database, kapan Google Sheets cukup

Google Sheets cukup selama otomasi kamu kecil, ditulis oleh satu atau dua workflow, dan datanya jauh dari batas 20 juta sel per file. Kamu butuh database saat data mulai dobel, beberapa proses menulis bersamaan, ada relasi antartabel, atau kuota API mulai menolak permintaan. Di antara keduanya, n8n punya Data Tables sebagai jalan tengah.

Tesis artikel ini: menurut saya, batas yang lebih dulu kamu tabrak adalah ketertiban data, jauh sebelum jumlah sel. Spreadsheet gagal pelan-pelan. Baris dobel, kolom yang diganti nama oleh rekan kerja, atau angka yang tersimpan sebagai teks. Database tidak membuat kamu lebih pintar, tetapi ia menolak data yang melanggar aturan sejak awal. Itu pembeda utamanya.

Yang perlu diluruskan dulu

Ada dua anggapan yang beredar. Pertama, "Google Sheets itu mainan, otomasi serius wajib pakai database." Kedua, kebalikannya, "Sheets cukup untuk semua, toh muat jutaan baris." Dua-duanya meleset.

Supaya istilahnya sama, saya definisikan dulu. Database adalah sistem penyimpanan data yang punya aturan ketat soal bentuk data, dan biasanya diakses lewat bahasa kueri seperti SQL. Google Sheets adalah spreadsheet berbasis web yang dibuat untuk dilihat dan diedit manusia, lalu bisa dibaca dan ditulis oleh program lewat API. API sendiri adalah pintu resmi yang dipakai program untuk berbicara dengan layanan lain.

Perbedaan desain itu yang menentukan semuanya. Sheets dirancang untuk mata manusia. Database dirancang untuk program yang menulis ribuan kali tanpa ada yang mengawasi. Otomasi berada di tengah-tengah, karena itu pilihannya tidak pernah hitam putih.

Catatan jujur. Artikel ini ditulis 2 November 2026. Angka batas dan kuota diambil langsung dari dokumentasi resmi Google, n8n, Supabase, dan PostgreSQL pada tanggal itu. Batas semacam ini bisa berubah, jadi cek ulang halaman sumbernya sebelum memutuskan. Artikel ini tidak memuat uji beban, jadi tidak ada angka "Sheets mulai lambat di baris ke sekian" di sini.

Artikel ini untuk kamu yang sudah membuat otomasi sederhana, misalnya formulir yang masuk ke Sheets atau pesanan yang dicatat oleh n8n, dan mulai ragu apakah fondasinya kuat. Artikel ini kurang berguna kalau kamu sedang membangun aplikasi dengan ribuan pengguna aktif. Untuk kasus itu, database sudah jelas jawabannya.

Batas resmi Google Sheets yang perlu kamu tahu

Mari mulai dari angka, karena banyak keputusan diambil berdasarkan rumor.

Batas ukuran file

Menurut halaman Bantuan Google Drive tentang file yang bisa disimpan, spreadsheet yang dibuat atau dikonversi ke Google Sheets bisa berisi hingga 20 juta sel atau 100 MB. Saat file Excel dikonversi, sel dengan lebih dari 50.000 karakter akan dihapus.

Dua puluh juta sel terdengar besar. Hitungannya kira-kira begini: dengan 20 kolom, itu setara satu juta baris. Dengan 40 kolom, tinggal setengahnya. Batas ini berlaku untuk seluruh file, jadi tab tambahan seperti "rekap", "arsip", dan "draft" ikut memakan jatah.

Untuk otomasi bisnis kecil yang menambah puluhan baris per hari, angka ini masih sangat jauh. Kecepatan file yang penuh rumus tidak saya beri angka, karena tidak ada batas resmi yang bisa dikutip.

Batas kuota API

Bagian ini yang lebih relevan untuk otomasi. Halaman batas penggunaan Google Sheets API menyebut kuota per menit berikut:

"Project" di sini adalah project Google Cloud tempat kredensial API kamu dibuat. Kuota terisi ulang setiap menit. Kalau dalam satu menit aplikasi mengirim 350 permintaan baca, 50 permintaan terakhir ditolak dengan kode 429, artinya terlalu banyak permintaan. Google menyarankan mencoba ulang dengan jeda yang makin panjang, pola yang disebut exponential backoff.

Ada beberapa detail lain dari halaman yang sama:

• Satu permintaan batch, yaitu beberapa perubahan yang dikirim sekaligus, dihitung sebagai satu permintaan.
• Permintaan yang diproses lebih dari 180 detik akan berakhir dengan galat batas waktu.
• Selama tetap di bawah kuota per menit, tidak ada batas jumlah permintaan per hari.
• Panggilan dari service account, yaitu akun khusus untuk program, dihitung sebagai satu akun.

Satu catatan lagi yang menarik. Halaman itu menyebut pemakaian standar Sheets API tidak dikenai biaya tambahan. Namun, permintaan yang melebihi kuota direncanakan mulai dikenai biaya di akun penagihan Google Cloud "later in 2026", tanpa tanggal pasti. Tarif dan tanggal berlakunya belum terverifikasi karena tidak tercantum di halaman itu.

Batas yang sering dilupakan: akses

Banyak orang mengandalkan fitur "Protect sheets and ranges" untuk menjaga data. Bantuan Google Docs Editors menulis terang-terangan bahwa fitur proteksi ini tidak boleh dipakai sebagai langkah keamanan. Orang yang bisa membuka file tetap bisa mencetak, menyalin, menempel, serta mengimpor dan mengekspor salinannya. Proteksi juga tidak bisa memakai kata sandi.

Artinya, siapa pun yang punya akses lihat ke spreadsheet pesanan bisa mengunduh seluruh daftar nomor WhatsApp pelanggan. Untuk data yang sensitif, ini alasan kuat untuk memisahkan penyimpanan dari tampilan.

Tanda otomasi kamu sudah butuh database

Angka batas jarang jadi pemicu pertama. Yang lebih mungkin terjadi adalah gejala kecil yang menumpuk. Berikut lima tanda yang menurut saya paling layak diperhatikan.

Data dobel yang sulit dicegah

Bayangkan webhook pembayaran terkirim dua kali karena gangguan jaringan. Di Sheets, workflow akan menambah dua baris yang sama, kecuali kamu memeriksa dulu sebelum menulis. Node Google Sheets di n8n punya operasi Append or Update Row yang memperbarui baris yang cocok, atau menambah baris baru bila tidak ada yang cocok. Ini membantu, tetapi pemeriksaannya terjadi di sisi workflow.

Database bekerja dari arah sebaliknya. Di PostgreSQL ada unique constraint, yaitu aturan yang menjamin nilai suatu kolom tidak boleh sama di antara semua baris. Kalau workflow mencoba menulis nomor invoice yang sudah ada, database menolaknya. Penjaganya ada di tempat data disimpan, bukan di setiap workflow yang menulis.

Beberapa proses menulis ke tempat yang sama

Selama hanya satu workflow yang menambah baris, Sheets nyaman dipakai. Masalah muncul saat formulir, toko online, dan admin yang mengetik manual menulis ke sheet yang sama. Daftar operasi node Google Sheets di n8n tidak memuat penguncian baris, jadi workflow tidak bisa berkata "kunci baris ini selama saya memperbaruinya".

Database dibuat untuk situasi ini. Node Postgres di n8n, menurut dokumentasinya, punya opsi Query Batching dengan mode Transaction. Dalam mode itu semua kueri dijalankan sebagai satu transaksi. Kalau satu gagal, semua perubahan dibatalkan. Transaksi adalah sekumpulan perubahan yang diperlakukan sebagai satu paket: berhasil semua atau tidak sama sekali.

Sebagai catatan adil, Sheets API juga menerapkan semua perubahan dalam satu permintaan secara atomik. Kalau satu bagian tidak valid, tidak ada perubahan yang diterapkan. Bedanya, itu berlaku per permintaan ke satu spreadsheet, sedangkan transaksi database bisa mencakup beberapa tabel sekaligus.

Struktur kolom berubah dan workflow ikut rusak

Contohnya sederhana. Rekan kerja mengganti judul kolom "No HP" menjadi "Nomor WhatsApp" agar lebih jelas. Besoknya workflow gagal. Dokumentasi n8n mencantumkan kasus ini di halaman masalah umum node Google Sheets: galat muncul kalau nama kolom berubah setelah node diatur, dan solusinya memuat ulang pemetaan kolom.

Di database, mengubah nama kolom adalah tindakan yang disengaja dan jarang dilakukan oleh orang yang hanya ingin merapikan tampilan. Jenis data juga dikunci. Dokumentasi PostgreSQL menyebut tipe data sebagai cara membatasi jenis data yang boleh masuk ke tabel, jadi kolom harga bertipe angka akan menolak teks "Rp 150rb".

Data mulai punya relasi

Pesanan punya pelanggan. Pelanggan punya beberapa alamat. Satu pesanan berisi beberapa produk. Di Sheets, relasi seperti ini biasanya diselesaikan dengan menyalin nama pelanggan ke setiap baris pesanan, atau dengan rumus VLOOKUP yang menjalar ke mana-mana.

Cara itu bekerja sampai pelanggan mengganti nomor telepon dan kamu harus memperbaruinya di 40 baris. Database relasional menyimpan pelanggan sekali, lalu pesanan cukup merujuk ke ID pelanggan. PostgreSQL menyediakan foreign key untuk menjaga rujukan itu tetap valid, dijelaskan di halaman constraint yang sama.

Kuota API mulai menolak

Kalau log n8n mulai menampilkan galat 429 dari Google, jangan langsung menambah jeda di mana-mana. Itu sinyal bahwa pola baca tulis kamu lebih cocok untuk database. Workflow yang membaca seluruh sheet setiap lima menit hanya untuk mencari satu baris adalah contoh klasiknya.

Data Tables di n8n: jalan tengah yang sering terlewat

n8n punya penyimpanan data sendiri yang mudah terlewat. Menurut dokumentasi Data tables, fitur ini menyimpan data terstruktur langsung di dalam n8n, sehingga kamu bisa menyimpan dan membaca data dari workflow tanpa sistem database eksternal.

Contoh pemakaian yang disebut n8n sendiri:

• Menyimpan data yang dipakai lintas workflow di project yang sama
• Menyimpan penanda untuk mencegah eksekusi ganda
• Menyimpan prompt atau pesan yang dipakai ulang
• Menyimpan data evaluasi untuk workflow AI
• Membuat tabel rujukan, misalnya daftar kode cabang dan nama kotanya

Node Data Table bisa membuat dan mengelola tabel, lalu menambah, memperbarui, menghapus, dan melakukan upsert baris. Upsert berarti perbarui kalau sudah ada, tambahkan kalau belum. Ada juga operasi If Row Exists dan If Row Does Not Exist yang praktis untuk mencegah data dobel. Tabel juga bisa dibuat dari impor CSV dan diunduh kembali sebagai CSV dari tab Data tables.

Batasnya

Bagian batas di dokumentasi resmi cukup jelas, dan ini yang menentukan apakah Data Tables cocok untukmu:

• Data Tables ditujukan untuk penyimpanan ringan sampai sedang. Secara default, total penyimpanan semua tabel dalam satu instance dibatasi 200 MiB. Di self-hosted, batas ini bisa diubah lewat variabel lingkungan.
• n8n memberi peringatan saat pemakaian mendekati 80% batas. Setelah batas terlampaui, penambahan manual dimatikan dan workflow yang mencoba menambah atau memperbarui data akan galat.
• Tabel yang dibuat dalam satu project bisa diakses semua anggota project itu. Admin dan Owner bisa melihat tabel semua pengguna.
• Code node tidak bisa mengakses Data Tables secara langsung.
• Menurut tabel perbandingan di halaman yang sama, Data Tables tidak bisa diakses lintas project.

Pendapat saya: Data Tables adalah pilihan terbaik untuk data milik workflow itu sendiri. Penanda "pesanan ini sudah diproses", log singkat, daftar rujukan, atau antrean kecil. Data jenis ini tidak perlu dilihat tim di luar n8n, dan menaruhnya di Sheets hanya menghabiskan kuota API.

Saya tidak menyarankan Data Tables sebagai satu-satunya tempat data bisnis utama, seperti seluruh riwayat transaksi pelanggan. Batas 200 MiB bisa jadi masalah di kemudian hari, dan data itu biasanya juga dibutuhkan aplikasi lain di luar n8n.

Tiga pilihan berdampingan

Setelah melihat batas masing-masing, saya memetakan pilihannya seperti diagram berikut. Mulai dari pertanyaan paling atas, lalu ikuti jawabanmu.

Tabel berikut merangkum perbedaannya dari sisi yang paling terasa saat membuat otomasi:

Kolom terakhir perlu sedikit penjelasan. Dokumentasi Data tables menyebut ada endpoint /datatables di API n8n untuk mengaksesnya secara terprogram. Jadi aksesnya tetap lewat n8n, bukan langsung.

Kenapa Supabase sering muncul dalam diskusi ini

Supabase adalah layanan database terkelola berbasis PostgreSQL. Menurut dokumentasi database Supabase, setiap project Supabase mendapat database Postgres penuh. Supabase mengelola backup harian, dan pemulihan ke titik waktu tertentu tersedia di paket berbayar. Ada juga Table Editor, yaitu tampilan mirip tabel di dashboard, jadi pemula tidak langsung berhadapan dengan layar SQL kosong.

Bagi pengguna n8n, ada dua jalur. Node Supabase menyediakan operasi dasar seperti membuat, mengambil, memperbarui, dan menghapus baris. Node Postgres bisa terhubung ke database Postgres mana pun, termasuk milik Supabase, dan punya operasi lebih lengkap seperti Insert or Update serta Execute Query. Saran saya: mulai dari node Supabase untuk operasi sederhana, lalu pakai node Postgres saat butuh transaksi atau kueri gabungan, karena opsi Transaction hanya tercantum di dokumentasi node Postgres.

Saya tidak membahas harga Supabase di sini karena berubah dari waktu ke waktu. Cek halaman harga resminya saat kamu memutuskan.

Pindah bertahap tanpa mengganggu tim

Keputusan pindah ke database sering tertunda karena satu ketakutan: tim sudah terbiasa membuka spreadsheet. Ketakutan itu wajar, dan solusinya tidak perlu memaksa semua orang belajar dashboard baru.

Pola yang saya sarankan: database sebagai sumber, Sheets sebagai jendela

Pola ini memisahkan dua peran. Database menjadi sumber kebenaran, yaitu satu-satunya tempat data dianggap benar. Google Sheets berubah peran menjadi jendela baca untuk tim. Workflow n8n terjadwal menyalin ringkasan atau laporan harian dari database ke Sheets.

Keuntungannya terasa di beberapa tempat. Rekan kerja yang mengganti judul kolom di Sheets tidak lagi merusak apa pun, karena workflow tidak membaca balik dari Sheets. Data sensitif bisa disaring sebelum disalin, misalnya nomor telepon hanya ditampilkan empat digit terakhir. Jumlah panggilan API ke Google juga turun, karena workflow cukup menulis sekali sehari.

Dalam pola ini, formulir dan sistem pesanan menulis ke database. Admin yang perlu mengoreksi data melakukannya di Table Editor atau lewat formulir khusus, bukan dengan mengetik langsung di spreadsheet laporan.

Urutan pindah yang realistis

Saya tidak menyarankan memindahkan semuanya dalam satu akhir pekan. Urutan yang lebih aman:

1. Petakan dulu. Daftar semua workflow yang membaca atau menulis ke spreadsheet, beserta kolom yang dipakai.
2. Pisahkan data internal workflow. Penanda proses, log, dan tabel rujukan dipindah ke Data Tables lebih dulu. Risikonya paling kecil dan langsung mengurangi panggilan API.
3. Rancang tabel utama. Tentukan kolom mana yang wajib unik, misalnya nomor invoice atau email pelanggan. Tentukan juga jenis datanya.
4. Jalankan berdampingan. Selama satu atau dua minggu, workflow menulis ke database dan Sheets sekaligus. Bandingkan hasilnya.
5. Balik arah. Setelah cocok, Sheets hanya diisi dari database lewat workflow terjadwal.

Langkah keempat mudah dilewati karena terasa membuang waktu. Padahal di tahap inilah bisa ketahuan bahwa ada kolom berisi campuran angka dan teks, atau tanggal dengan dua format berbeda. Node Postgres di n8n bahkan punya opsi untuk mengganti string kosong menjadi NULL, dan dokumentasinya menyebut opsi itu berguna untuk data yang berasal dari spreadsheet.

Kapan tetap bertahan di Sheets

Supaya adil, ada kasus ketika saya justru menyarankan tetap di Sheets:

• Satu workflow menulis, satu atau dua orang membaca, dan datanya bertambah puluhan baris per hari.
• Data dipakai untuk kolaborasi aktif, misalnya kalender konten yang diedit bergantian oleh tim.
• Proyek masih tahap uji ide dan belum jelas akan bertahan berapa lama.
• Tidak ada orang di tim yang sanggup merawat database, termasuk memantau backup.

Poin terakhir mudah diremehkan. Database yang tidak dirawat lebih berbahaya daripada spreadsheet yang dirawat. Kalau kamu memilih database terkelola seperti Supabase, beban itu berkurang, tetapi tetap ada yang perlu dipahami.

Ringkasan dan langkah berikutnya

Checklist sebelum memutuskan

• Saya tahu berapa workflow yang menulis ke spreadsheet yang sama
• Saya sudah memeriksa log n8n untuk galat 429 dari Google Sheets
• Saya tahu apakah semua workflow memakai satu kredensial Google yang sama
• Saya sudah menghitung kasar jumlah sel di file terbesar (baris kali kolom, semua tab)
• Saya tahu kolom mana yang seharusnya unik dan pernah dobel
• Saya sudah memisahkan data internal workflow dari data yang dibaca tim
• Saya tahu siapa saja yang punya akses ke spreadsheet berisi data pelanggan
• Ada orang yang bertanggung jawab merawat database bila saya pindah

Cheat sheet

Kalau kamu memutuskan Google Sheets masih cukup, langkah berikutnya adalah membuat otomasinya lebih tertib. Pakai satu sheet per jenis data, jangan ubah judul kolom sembarangan, dan beri kolom ID unik di setiap baris. Otomasi Google Sheets di eduwebmu bisa jadi titik awal untuk menyusun alur seperti itu. Kalau suatu hari tanda-tanda di atas mulai muncul, struktur yang rapi juga membuat perpindahan ke database jauh lebih mudah.