PostgreSQL ke Google Sheets: 4 Cara yang Bekerja

Bayangkan skenario ini: laporan laba rugi triwulanan sudah siap dipresentasikan ke direksi, tapi angka gross margin di Sheets berbeda Rp 340 juta dari yang ada di sistem - ternyata file CSV yang digunakan sudah tiga hari basi. Bagi analis keuangan yang mengelola laporan mingguan, ini bukan skenario hipotetis. Ini realitas yang cepat atau lambat dialami oleh siapa pun yang masih mengandalkan ekspor manual.

Ada empat cara menghubungkan PostgreSQL ke Google Sheets: ekspor CSV manual, Apps Script dengan JDBC (butuh developer), konektor ETL pihak ketiga, atau query langsung melalui DuckDB. Untuk kebutuhan satu kali, CSV sudah cukup. Tapi jika laporan Anda harus selalu mencerminkan data terkini - bukan snapshot dari tiga hari lalu - Anda perlu salah satu dari tiga pendekatan lainnya.

Mengapa Data Basi di Spreadsheet Itu Masalah Nyata

Alur kerja ekspor-dan-tempel bukan sekadar merepotkan - ini menciptakan risiko yang nyata. Setiap kali Anda mengunduh CSV dan menempelnya ke Sheets, Anda sedang membuat salinan statis dari data pada satu titik waktu tertentu. Masalahnya, orang-orang memperlakukan data itu seolah-olah selalu mutakhir.

Menurut survei Fivetran tahun 2023, 67% analis data menghabiskan lebih dari 4 jam per minggu untuk tugas pemindahan data manual yang sebenarnya bisa diotomasi. Bagi tim FP&A yang menjalankan siklus pelaporan mingguan, data Postgres yang sudah basi berarti angka laba rugi tertinggal berhari-hari dari transaksi aktual - tepat pada momen ketika keakuratan angka paling krusial.

Ini bukan soal kompetensi teknis. Masalahnya ada pada jalur termudah yang tersedia: unduh CSV, tempel ke Sheets, kirim ke atasan. Jalur itu tidak bisa diandalkan begitu skalanya bertambah.

Empat Cara Menghubungkan PostgreSQL ke Google Sheets

Kolom "Butuh programmer?" adalah pertimbangan yang sering tidak muncul dalam panduan teknis. Bagi analis keuangan yang tidak punya akses langsung ke database - dan tidak seharusnya mengurus infrastruktur sendiri - pilihan yang bisa dijalankan secara mandiri sangat berbeda dari pilihan yang memerlukan keterlibatan tim IT.

Ekspor CSV: Untuk Kebutuhan Sesekali, Bukan Laporan Rutin

Jika Anda hanya perlu snapshot data untuk analisis satu kali, ekspor CSV dari klien PostgreSQL seperti pgAdmin, DBeaver, atau TablePlus selesai dalam lima menit. Anda bisa meminta kolega di tim IT untuk mengeksekusi query yang dibutuhkan dan mengekspor hasilnya - tidak perlu akses database langsung.

Batas pendekatannya jelas: tidak ada otomasi, tidak ada refresh, tidak ada jaminan bahwa angka yang ada di Sheets adalah angka yang benar hari ini.

Apps Script + JDBC: Butuh Keterlibatan Developer dan IT

Google Apps Script mendukung koneksi JDBC langsung ke PostgreSQL. Seorang developer bisa menulis fungsi yang membuka koneksi, menjalankan query, dan menulis hasilnya ke named range di Sheets secara terjadwal. Hasilnya bisa otomatis - tapi ada tiga pertanyaan penting yang perlu dijawab sebelum Anda membawa opsi ini ke atasan.

Siapa yang akan maintain-nya? Setiap perubahan pada skema database, rotasi password, atau perpindahan server memerlukan pembaruan manual pada skrip. Jika developer yang membuatnya sudah tidak ada di tim, Anda mewarisi kode yang tidak Anda pahami - dan tidak ada yang jelas bertanggung jawab memperbaikinya kalau tiba-tiba mati.

Apakah IT akan menyetujui konfigurasi jaringannya? Koneksi JDBC di Google mengharuskan instance PostgreSQL Anda dapat diakses dari rentang IP Google - sebuah kompromi keamanan yang tidak akan disetujui oleh banyak tim IT. Per Maret 2026, Google tidak mempublikasikan daftar IP Apps Script yang stabil untuk keperluan allowlisting, sehingga konfigurasi firewall menjadi tidak pasti.

Di mana kredensial disimpan? Apps Script menyimpan password database di script properties yang bisa dilihat oleh siapa pun yang memiliki akses editor ke spreadsheet tersebut. Dokumentasi Google Apps Script secara eksplisit menyebutkan bahwa "script properties dibagikan kepada semua pengguna skrip" - artinya setiap kolaborator di file Anda berpotensi membaca password database tersebut.

Bagi tim yang punya kapasitas teknis dan kendali infrastruktur yang memadai, Apps Script bisa menjadi solusi tanpa biaya. Bagi sebagian besar tim FP&A, biaya pemeliharaan tersembunyinya lebih mahal dari yang terlihat.

Konektor ETL: Tepat untuk Organisasi Besar, Berlebihan untuk yang Lain

Alat seperti Fivetran, Airbyte, dan Stitch dapat menyinkronkan tabel Postgres ke Google Sheets atau BigQuery secara terjadwal. Setup awal memerlukan keterlibatan IT, namun setelah berjalan, sinkronisasi bersifat otomatis sepenuhnya.

Konsekuensinya ada pada biaya dan fleksibilitas. Paket dasar Fivetran mulai dari sekitar Rp 1.600.000 per bulan dengan harga berdasarkan jumlah baris aktif. Tier cloud Airbyte mulai dari sekitar Rp 48.000 per satu juta rekaman yang disinkronkan. Untuk perusahaan yang perlu menyinkronkan puluhan tabel setiap hari, biaya ini wajar. Untuk analis yang butuh satu atau dua query spesifik untuk laporan mingguan, ini jauh melebihi kebutuhan.

Konektor ETL juga mereplikasi seluruh tabel, bukan query kustom. Jika Anda butuh join beberapa tabel dengan filter kondisi tertentu, logika itu harus dibuat di hilir - bukan di sumber. Artinya, Anda tetap menulis formula kompleks di Sheets atau SQL di BigQuery setelah data masuk.

Query PostgreSQL Langsung di Google Sheets dengan DuckDB

DuckDB menyertakan ekstensi inti bernama postgres yang menghubungkan database PostgreSQL sebagai sumber data yang bisa di-query langsung - tanpa replikasi, tanpa warehouse perantara. Anda menulis permintaan dalam bahasa biasa, dan hasilnya langsung muncul di sheet Anda.

Bagi analis keuangan, perbedaan praktisnya konkret. Alih-alih mendapat dump tabel transaksi generik yang masih harus diolah, Anda bisa meminta output yang sudah berbentuk laporan laba rugi. Di balik layar, permintaan seperti "tampilkan laba kotor per bulan untuk 12 bulan terakhir" menghasilkan query seperti ini:

SELECT
  date_trunc('month', t.created_at)   AS bulan,
  SUM(t.pendapatan)                    AS pendapatan,
  SUM(t.hpp)                           AS hpp,
  SUM(t.pendapatan) - SUM(t.hpp)       AS laba_kotor,
  ROUND(
    (SUM(t.pendapatan) - SUM(t.hpp))
    / NULLIF(SUM(t.pendapatan), 0) * 100, 1
  )                                    AS margin_kotor_pct
FROM pg.laporan_keuangan t
WHERE t.created_at >= CURRENT_DATE - INTERVAL '12 months'
GROUP BY 1
ORDER BY 1 DESC;

Anda tidak perlu menulis SQL ini sendiri. Yang penting adalah outputnya - langsung masuk ke sheet sebagai tabel terstruktur yang bisa segera dimasukkan ke model keuangan atau pitch deck:

Angkanya sudah berupa nilai numerik - bukan teks - sehingga langsung bisa dirujuk oleh tab lain di model Anda. ModelMonkey menggunakan arsitektur DuckDB ini untuk memungkinkan query dalam bahasa biasa langsung dari sidebar Sheets, tanpa menulis SQL sama sekali. Hasilnya langsung ke sheet aktif, dan bisa dijalankan ulang kapan saja dengan satu klik - tidak ada skrip yang perlu di-maintain, tidak ada pipeline yang perlu dimonitor.

Yang Perlu Anda Tanyakan ke Tim IT

Untuk pendekatan apa pun selain CSV manual, Anda perlu kredensial koneksi ke database. Yang benar dilakukan bukanlah meminta akun admin - cukup minta akses read-only yang terbatas pada tabel yang relevan. Berikut tiga permintaan konkret yang bisa langsung Anda sampaikan ke DBA atau tim IT:

Minta akun read-only dengan akses terbatas:

"Saya butuh akun PostgreSQL read-only yang hanya bisa mengakses schema financials, khususnya tabel transactions, products, dan accounts. Tidak perlu akses write atau akses ke tabel lain."

Tanyakan soal jalur koneksi yang aman:

"Apakah ada opsi koneksi melalui VPN atau SSH tunnel? Saya tidak ingin membuka akses publik ke database - saya hanya butuh koneksi yang aman dari laptop saya."

Minta format koneksi yang lengkap:

"Bisakah saya mendapatkan connection string-nya? Format yang saya butuhkan: host, port, nama database, username, dan password."

Tim IT yang baik akan langsung memahami permintaan ini. Akun read-only dengan akses schema terbatas adalah praktik standar - jauh lebih mudah disetujui daripada meminta akses penuh atau membuka port database ke publik.

Langkah Awal Menghubungkan PostgreSQL ke Google Sheets

Begitu Anda punya kredensial read-only dari IT, prosesnya straightforward:

1. Buka sidebar di Google Sheets
2. Masuk ke Data Sources → Add Connection
3. Pilih PostgreSQL sebagai jenis koneksi
4. Masukkan host, port, nama database, dan schema
5. Masukkan kredensial - gunakan solusi yang mengenkripsi dan tidak menyimpan password dalam bentuk plaintext
6. Klik Test Connection untuk verifikasi
7. Jalankan query pertama Anda - mulai dengan sesuatu yang sederhana, misalnya pendapatan 30 hari terakhir per kategori produk

Setelah koneksi tersimpan, Anda bisa menjalankan query ke sheet mana pun di workbook Anda. Model multi-tab yang sudah ada tetap bisa berjalan seperti biasa - output dari Postgres masuk ke tab data yang Anda tentukan, dan formula di tab lain yang merujuk ke range tersebut akan otomatis mengambil nilai terbaru.

FAQ

Bisakah PostgreSQL dihubungkan ke Google Sheets tanpa menulis kode?

Ya. Pendekatan berbasis DuckDB memungkinkan Anda mengetikkan permintaan dalam bahasa biasa - misalnya "tampilkan pendapatan per bulan dibandingkan HPP untuk 12 bulan terakhir" - dan mendapatkan tabel langsung di sheet Anda. Anda tidak perlu menulis SQL, tidak perlu menyentuh konfigurasi server. Yang Anda butuhkan hanya kredensial koneksi read-only dari tim IT, yang bisa Anda minta menggunakan template permintaan di bagian atas artikel ini.

Seberapa sering data Postgres bisa diperbarui secara otomatis di Sheets?

Bergantung pada metode yang digunakan. Dengan Apps Script, refresh bisa dijadwalkan setiap jam atau setiap hari - namun memerlukan setup developer dan pemeliharaan berkelanjutan. Dengan konektor ETL, sinkronisasi bisa berjalan setiap 15 menit hingga harian sesuai paket berlangganan. Dengan pendekatan DuckDB, refresh berjalan on-demand: setiap kali Anda menjalankan query, Anda mendapatkan data terkini langsung dari Postgres - bukan dari cache atau salinan yang sudah basi. Untuk laporan mingguan tim FP&A, pendekatan on-demand biasanya sudah cukup: jalankan sebelum meeting, angkanya selalu aktual.

Apa risiko keamanan menyimpan kredensial Postgres di Google Apps Script?

Risiko utamanya ada pada visibilitas yang tidak terduga. Apps Script menyimpan password di script properties yang bisa diakses oleh semua kolaborator dengan akses editor pada spreadsheet - termasuk orang-orang yang mungkin tidak Anda sadari memiliki akses. Jika spreadsheet pernah dibagikan ke vendor eksternal atau konsultan, mereka berpotensi membaca kredensial database Anda. Mitigasi minimalnya: gunakan akun database read-only dengan akses schema terbatas, bukan akun admin; dan audit daftar editor spreadsheet secara berkala. Solusi yang lebih aman menggunakan enkripsi sehingga password tidak pernah tersimpan dalam bentuk plaintext - ini standar yang sebaiknya Anda tanyakan ke vendor sebelum memilih alat.