TL;DR
PostgreSQL adalah database baris yang dirancang buat aplikasi: baca-tulis cepat di sedikit baris, dibantu index. BigQuery adalah data warehouse kolom yang dirancang buat analisis: scan miliaran baris sekaligus, tanpa index, dan kamu bayar per byte yang discan. Kalau query kamu nyentuh satu-dua baris, pakai PostgreSQL. Kalau kamu ngagregasi jutaan baris buat laporan, pakai BigQuery.
PostgreSQL dan BigQuery sama-sama pakai SQL, tapi dibangun buat pekerjaan yang beda. PostgreSQL cepat kalau kamu ambil sedikit baris. BigQuery cepat kalau kamu scan miliaran baris sekaligus.
Salah pilih, dan kamu bakal dapat dashboard yang lemot atau tagihan cloud yang bikin bos kaget.
Aku bandingin di sini dari sisi arsitektur, biaya, dan kebiasaan nulis query, termasuk hal-hal yang bikin query kamu tiba-tiba mahal setelah pindah ke BigQuery.
Beda utamanya di cara nyimpen data. PostgreSQL nyimpen per baris. BigQuery nyimpen per kolom.
Kedengeran teknis, tapi konsekuensinya kerasa banget di kerjaan sehari-hari.
Di PostgreSQL, satu transaksi penjualan disimpan sebagai satu blok utuh. Mau ambil semua detail transaksi nomor 84120? Sekali baca, dapat semua. Cepat.
Di BigQuery, kolom cabang disimpan terpisah dari kolom produk, terpisah lagi dari qty. Mau ambil satu transaksi utuh? Dia harus baca dari beberapa tempat, terus rakit lagi. Boros.
Tapi kalau kamu mau SUM(qty) dari 500 juta baris? BigQuery cuma baca satu kolom, kolom qty, dan skip sisanya. PostgreSQL harus baca semua baris utuh dulu, termasuk kolom yang nggak dipakai.
Itu inti bedanya. Sisanya turunan dari sini.
| Aspek | PostgreSQL | BigQuery |
|---|---|---|
| Penyimpanan | Per baris | Per kolom |
| Dirancang buat | Aplikasi (OLTP) | Analisis (OLAP) |
| Percepat query pakai | Index | Partisi + cluster |
| Ambil 1 baris | Milidetik | Ratusan milidetik-detik |
| Scan 1 miliar baris | Menit sampai jam | Detik |
| Update 1 baris | Murah, biasa | Mahal, dihindari |
| Model biaya | Per jam server nyala | Per byte yang discan |
| Ngatur server | Kamu (atau RDS) | Nggak ada server |
| Ukuran data ideal | Sampai ratusan GB | Ratusan GB sampai petabyte |
Aturan gampangnya: PostgreSQL buat nulis, BigQuery buat mikir.
Setup yang paling umum di perusahaan: PostgreSQL nampung data aplikasi, terus tiap malam datanya disalin ke BigQuery buat dianalisis. Dua-duanya jalan bareng.
Di PostgreSQL, SELECT * itu kebiasaan yang paling parah cuma bikin sedikit boros. Di BigQuery, itu langsung nambah tagihan.
Kamu bayar per byte kolom yang dibaca. Tabel dengan 30 kolom, dan kamu cuma butuh 3? Sebut 3 aja.
-- Mahal: baca semua 30 kolom
SELECT * FROM `tokoberkah.penjualan`
WHERE tanggal >= '2026-05-01';
-- Murah: baca 3 kolom doang
SELECT cabang, qty, harga_satuan
FROM `tokoberkah.penjualan`
WHERE tanggal >= '2026-05-01';BigQuery nggak punya index. Yang dia punya: partitioning. Tabel yang dipartisi per tanggal bikin WHERE tanggal = '2026-05-12' cuma baca data satu hari, bukan seluruh tabel.
CREATE TABLE `tokoberkah.penjualan_part`
PARTITION BY DATE(tanggal)
CLUSTER BY cabang AS
SELECT * FROM `tokoberkah.penjualan`;Ini biasanya perubahan yang paling besar dampaknya ke biaya. Kalau tabel kamu punya kolom tanggal dan sering difilter pakai tanggal, partisi itu wajib.
Di PostgreSQL, UPDATE ... WHERE id = 5 itu murah dan biasa. Di BigQuery, itu operasi berat. Dia harus nulis ulang blok data yang besar.
Pola di BigQuery: tulis data baru sebagai baris baru (append), terus ambil versi terbaru waktu query. Bukan ubah yang lama.
Editor BigQuery nunjukin estimasi byte sebelum kamu klik Run. Baca angkanya. Kalau tulisannya "This query will process 1.4 TB", jangan langsung klik.
Dataset toko_berkah versi besar di ngulikdata: 6 cabang, data 3 tahun, 42 juta baris transaksi, tabel 30 kolom.
Query yang mau dijalanin: omzet per cabang bulan Mei 2026.
SELECT
cabang,
SUM(qty * harga_satuan) AS omzet
FROM penjualan
WHERE tanggal BETWEEN '2026-05-01' AND '2026-05-31'
GROUP BY cabang
ORDER BY omzet DESC;Hasil perbandingan waktu aku jalanin di dua tempat:
| Skenario | Waktu | Catatan |
|---|---|---|
| PostgreSQL, tanpa index tanggal | ~52 detik | Full table scan 42 juta baris |
| PostgreSQL, pakai index tanggal | ~4 detik | Cuma baca baris Mei |
| BigQuery, tabel tanpa partisi, SELECT * | ~6 detik | Scan 11 GB |
| BigQuery, tabel tanpa partisi, 4 kolom | ~3 detik | Scan 1,3 GB |
| BigQuery, partisi tanggal, 4 kolom | ~2 detik | Scan 38 MB |
Perhatiin baris terakhir. Byte yang discan turun dari 11 GB ke 38 MB (sekitar 290x lebih sedikit) cuma dengan dua perubahan: partisi tanggal dan nyebut kolom yang dipakai.
Kecepatannya cuma naik dikit (6 detik jadi 2 detik). Tapi biayanya yang beda jauh. Kalau query ini jalan tiap 15 menit di dashboard, versi borosnya bisa nghabisin ratusan GB scan per hari.
Dan buat data segini, PostgreSQL yang di-index masih kompetitif. BigQuery baru menang telak waktu datanya nyampe ratusan juta sampai miliaran baris.
Buat aplikasi, nggak. BigQuery lambat kalau cuma ambil satu baris, latensinya ratusan milidetik sampai detik, dan nggak dirancang buat update satu baris terus-terusan. PostgreSQL bisa nangani ribuan transaksi per detik. Yang umum: PostgreSQL buat aplikasi, datanya disalin ke BigQuery buat analisis. Dua-duanya jalan, tugasnya beda.
BigQuery nyimpen data per kolom, dan kamu bayar per byte kolom yang dibaca. SELECT * berarti dia baca semua kolom, termasuk kolom teks panjang yang nggak kamu pakai. Di PostgreSQL yang nyimpen per baris, baca satu kolom atau semua kolom hampir sama bebannya. Di BigQuery, nyebut 3 kolom dari 30 bisa mangkas biaya sampai 90%.
Nggak ada index kayak di PostgreSQL. Gantinya ada partitioning (misal per tanggal) dan clustering (misal per cabang). Partitioning bikin BigQuery cuma baca partisi yang relevan, jadi WHERE tanggal = '2026-05-12' cuma nyentuh data satu hari. Ini yang paling ngaruh ke biaya dan kecepatan di BigQuery.
Tergantung pola pakai. BigQuery bayar per byte yang discan. Kalau kamu jarang query tapi datanya besar, ini murah banget. PostgreSQL bayar per jam server nyala, jadi kalau server nyala 24 jam tapi query jarang, kamu tetap bayar. Yang bikin BigQuery mahal itu query boros yang jalan tiap 5 menit di dashboard.
Dasarnya sama: SELECT, WHERE, GROUP BY, JOIN, window function jalan mirip. Yang beda di detail. BigQuery pakai backtick buat nama tabel dan format project.dataset.tabel. Tipe datanya beda dikit. BigQuery punya ARRAY dan STRUCT yang dipakai sehari-hari. Fungsi tanggal juga beda nama. Sekitar 90% query kamu bakal langsung jalan, sisanya perlu disesuaikan.
Ringkasannya:
Latihan query agregasi yang jalan di dua-duanya di halaman SUM dan GROUP BY, atau baca definisi data warehouse di glossary. Buat detail model biaya, baca dokumentasi resmi BigQuery soal pengendalian biaya.
Lanjut baca: Data Wrangling: Kenapa Makan 70% Waktu Analis dan Belajar SQL Pakai AI.
Mau praktek langsung? Mulai latihan SQL gratis
Latihan interaktif, langsung di browser.
Analisa per kuartal, hari kerja, atau musim jadi ribet kalau tiap query ngitung ulang atribut tanggal. Tabel kalender nyimpen semua atribut itu sekali, biar tinggal di-JOIN.
Laporan penjualan harian sering bolong di hari tanpa transaksi. Ini cara bikin deret tanggal lengkap di SQL biar tiap hari muncul, walau nilainya nol.
Struktur organisasi tersimpan sebagai kolom id_atasan yang saling nunjuk. Ini cara narik rantai jabatan, hitung total bawahan, dan span of control cuma pakai SQL.