TL;DR
Snowflake adalah gudang data berbasis cloud yang misahin penyimpanan dari komputasi. Data disimpan sekali di satu tempat, sementara tenaga pengolahnya berupa virtual warehouse yang bisa dinyalain, dibesarkan, atau dimatiin sesuai kebutuhan. Biayanya dihitung dari kredit yang kepakai per detik waktu warehouse aktif, ditambah biaya penyimpanan per terabyte. Buat analis, bahasa querynya SQL standar, jadi yang perlu dipelajari terutama soal warehouse, database, dan cara ngatur biaya.
Snowflake adalah gudang data berbasis cloud yang misahin tempat nyimpen data dari tenaga yang ngolahnya. Data kamu disimpan sekali, terus siapa pun yang mau query bisa nyalain mesinnya sendiri tanpa saling rebutan.
Ini yang bikin dia beda dari database tradisional. Di PostgreSQL, kalau tim marketing jalanin query berat, tim keuangan ikut kena lambat. Di Snowflake, keduanya bisa pakai mesin terpisah yang baca data yang sama.
Buat kamu sebagai analis, bahasa yang dipakai tetap SQL standar. Yang perlu kamu pelajari baru bukan sintaksnya, tapi cara ngatur mesin dan biayanya.
Snowflake adalah platform data yang jalan sepenuhnya di cloud, tanpa perangkat keras atau perangkat lunak yang perlu kamu pasang sendiri. Dia jalan di atas AWS, Microsoft Azure, atau Google Cloud, tapi kamu nggak berurusan langsung sama infrastrukturnya. Yang kamu lihat cuma antarmuka web dan editor SQL.
Arsitekturnya punya tiga lapis yang terpisah:
Lapis penyimpanan. Semua tabel disimpan di penyimpanan objek cloud dalam format terkompresi berbasis kolom. Kamu bayar per terabyte per bulan.
Lapis komputasi. Ini yang disebut virtual warehouse. Kumpulan mesin yang ngerjain query kamu. Bisa dinyalain, dimatiin, dan dibesarkan kapan saja.
Lapis layanan cloud. Ngurusin autentikasi, metadata, optimasi query, dan kontrol akses. Ini yang bikin kamu nggak perlu bikin index atau ngatur partisi manual.
Pemisahan lapis pertama dan kedua itu inti keseluruhan idenya. Dokumentasi resmi arsitekturnya ada di panduan konsep kunci Snowflake.
Virtual warehouse adalah kumpulan sumber daya komputasi yang ngerjain query kamu. Namanya membingungkan soalnya dia nggak nyimpen data sama sekali. Anggap saja itu mesin yang kamu sewa per detik buat baca dan ngolah data yang tersimpan di lapis penyimpanan.
Ukurannya bertingkat dari XS sampai 6XL. Tiap naik satu tingkat, jumlah mesinnya dua kali lipat, dan konsumsi kreditnya juga dua kali lipat.
| Ukuran | Kredit per jam | Cocok buat |
|---|---|---|
| X-Small | 1 | Query harian analis, eksplorasi data |
| Small | 2 | Dashboard dengan beberapa pengguna |
| Medium | 4 | Transformasi data harian |
| Large | 8 | Pemuatan data besar, join tabel raksasa |
| X-Large | 16 | Beban kerja berat terjadwal |
Yang penting kamu pahami: naik ukuran nggak selalu bikin query lebih cepat. Warehouse yang lebih besar nolong buat query yang bisa dipecah paralel dan buat data yang besar. Query sederhana di tabel kecil jalannya sama saja di XS dan di Large, tapi biayanya delapan kali lipat.
CREATE WAREHOUSE analis_wh
WAREHOUSE_SIZE = 'XSMALL'
AUTO_SUSPEND = 60
AUTO_RESUME = TRUE
INITIALLY_SUSPENDED = TRUE;
USE WAREHOUSE analis_wh;Dua parameter di situ yang paling ngaruh ke tagihan.
AUTO_SUSPEND = 60 matiin warehouse setelah 60 detik nganggur. Tanpa ini, warehouse kamu nyala terus dan kredit kebakar walaupun nggak ada yang query.
AUTO_RESUME = TRUE nyalain lagi otomatis waktu ada query masuk. Jeda nyalanya biasanya cuma beberapa detik.
Kombinasi keduanya bikin kamu bayar mendekati waktu pakai sebenernya.
Susunannya tiga tingkat: database, lalu schema, lalu tabel. Nama lengkap sebuah tabel jadi database.schema.tabel.
CREATE DATABASE penjualan;
CREATE SCHEMA penjualan.publik;
CREATE TABLE penjualan.publik.transaksi (
transaksi_id NUMBER,
waktu_transaksi TIMESTAMP_NTZ,
kota VARCHAR(50),
kategori_produk VARCHAR(50),
total_belanja NUMBER(12,2)
);Biar nggak perlu nulis nama panjang tiap query, setel konteks di awal sesi:
USE WAREHOUSE analis_wh;
USE DATABASE penjualan;
USE SCHEMA publik;
SELECT kota, SUM(total_belanja) AS omzet
FROM transaksi
WHERE waktu_transaksi >= '2025-09-01'
GROUP BY kota
ORDER BY omzet DESC;Setelah konteks disetel, kamu nulis SQL biasa. Sintaksnya mengikuti standar ANSI, jadi kalau kamu udah bisa aggregate function dan window function di PostgreSQL, hampir semuanya jalan langsung.
Snowflake nyimpen versi lama tabel selama beberapa hari. Kamu bisa baca isi tabel di titik waktu tertentu, atau balikin tabel yang kehapus.
SELECT * FROM transaksi
AT (OFFSET => -3600);
SELECT * FROM transaksi
BEFORE (STATEMENT => '01b2c3d4-0000-0000-0000-000000000001');
UNDROP TABLE transaksi;Query pertama nunjukin isi tabel satu jam lalu. Yang terakhir balikin tabel yang baru saja kehapus.
Masa simpan bawaannya 1 hari di edisi Standard, dan bisa disetel sampai 90 hari di edisi Enterprise. Ini pengaman yang sering nyelametin waktu ada yang jalanin UPDATE tanpa WHERE.
Kamu bisa bikin salinan database atau tabel tanpa nggandain datanya secara fisik.
CREATE DATABASE penjualan_uji CLONE penjualan;Perintah ini jalan dalam hitungan detik walaupun databasenya terabyte. Snowflake cuma nyalin metadata, dan baru nyimpen data baru waktu ada perubahan.
Buat analis, ini artinya kamu bisa punya lingkungan uji coba pribadi tanpa nambah biaya penyimpanan yang berarti.
Kolom bertipe VARIANT bisa nyimpen JSON langsung, dan kamu query pakai notasi titik.
SELECT
respons:pelanggan.nama::STRING AS nama,
respons:pelanggan.kota::STRING AS kota,
respons:total::NUMBER AS total
FROM log_pesanan
WHERE respons:status::STRING = 'sukses';Nggak perlu bikin tabel perantara buat data dari API. Ini kepakai banget kalau sumber data kamu dari aplikasi mobile atau webhook e-commerce.
Tagihan Snowflake punya dua komponen utama.
Kredit komputasi. Dihitung dari ukuran warehouse dikali waktu nyala, ditagih per detik dengan minimum 60 detik tiap kali warehouse nyala. Harga per kredit tergantung edisi dan region cloud kamu, tercantum di halaman harga resmi Snowflake.
Penyimpanan. Dihitung dari rata-rata data terkompresi per bulan, per terabyte.
Buat sebagian besar tim analis, komputasi jauh lebih besar dari penyimpanan. Jadi di situ fokus penghematan kamu.
Anggap satu tim berisi 5 analis yang masing-masing aktif query 3 jam per hari kerja, pakai warehouse X-Small bersama.
| Pengaturan | Jam warehouse nyala per bulan | Kredit terpakai |
|---|---|---|
| Tanpa auto-suspend, nyala 24 jam | 720 | 720 |
| Auto-suspend 10 menit | 154 | 154 |
| Auto-suspend 60 detik | 78 | 78 |
Selisih baris pertama dan terakhir itu 9 kali lipat. Beda pengaturannya cuma satu angka.
Angka 78 jam itu lebih kecil dari total 5 analis kali 3 jam kali 22 hari, soalnya waktu query mereka sering tumpang tindih dan warehouse yang sama melayani semuanya.
Snowflake nyimpen riwayat pemakaian di schema khusus. Query ini nunjukin kredit per warehouse 30 hari terakhir:
SELECT
warehouse_name,
ROUND(SUM(credits_used), 2) AS total_kredit
FROM snowflake.account_usage.warehouse_metering_history
WHERE start_time >= DATEADD('day', -30, CURRENT_TIMESTAMP())
GROUP BY warehouse_name
ORDER BY total_kredit DESC;Jalanin sebulan sekali. Biasanya ketahuan satu warehouse yang lupa dimatiin sejak proyek selesai.
| Aspek | Snowflake | BigQuery | PostgreSQL |
|---|---|---|---|
| Dasar penagihan | Waktu warehouse nyala | Byte yang dipindai | Server yang kamu sewa |
| Pilihan cloud | AWS, Azure, GCP | Google Cloud saja | Di mana saja |
| Perlu atur index? | Nggak | Nggak | Ya |
| Kontrol biaya utama | Auto-suspend dan ukuran warehouse | Partisi dan pemilihan kolom | Ukuran server |
| Cocok buat | Banyak tim dengan beban berbeda | Beban tak menentu, ekosistem Google | Data kecil sampai menengah |
Perbedaan cara nagih itu yang paling ngaruh ke kebiasaan kerja kamu. Di BigQuery, query yang jalan lama tapi baca sedikit data itu murah. Di Snowflake, query yang jalan lama itu mahal, tapi kamu bisa jalanin sepuluh query berturut-turut dalam satu jam warehouse tanpa tambahan biaya.
Kalau kamu penasaran sama sisi BigQuery-nya, baca panduan partisi dan clustering BigQuery.
Ini contoh alur kerja analis di Snowflake, pakai data penjualan 240 juta baris dari jaringan toko kelontong.
USE WAREHOUSE analis_wh;
USE DATABASE penjualan;
USE SCHEMA publik;
CREATE OR REPLACE TABLE ringkasan_bulanan AS
SELECT
kota,
kategori_produk,
DATE_TRUNC('month', waktu_transaksi) AS bulan,
COUNT(*) AS jumlah_transaksi,
SUM(total_belanja) AS omzet,
ROUND(AVG(total_belanja), 0) AS rata_belanja
FROM transaksi
WHERE waktu_transaksi >= '2025-01-01'
GROUP BY 1, 2, 3;Tabel ringkasan ini isinya cuma sekitar 660 baris, dari 240 juta baris sumber. Semua dashboard dan laporan baca dari tabel kecil ini, bukan dari tabel mentah.
Perbandingan waktu dan kredit di warehouse X-Small:
| Cara | Waktu query | Kredit terpakai |
|---|---|---|
| Dashboard baca langsung tabel mentah, 12 kali sehari | 34 detik per query | 0,11 per hari |
| Bikin ringkasan sekali, dashboard baca ringkasan | 0,4 detik per query | 0,02 per hari |
Hemat kreditnya 5 kali lipat, dan dashboard-nya kebuka hampir seketika. Pola ini yang paling sering ngasih hasil di tim kecil.
Lupa nyetel auto-suspend. Ini penyebab tagihan membengkak nomor satu. Warehouse yang nyala semalaman tanpa ada yang query tetap ngabisin kredit penuh.
Naikin ukuran warehouse buat query yang lambat. Cek dulu penyebab lambatnya. Kalau masalahnya query yang nggak efisien atau tabel yang kegedean, warehouse besar cuma bikin mahal tanpa banyak perbaikan.
Pakai satu warehouse buat semua orang. Pisahkan warehouse per tim atau per jenis beban kerja. Selain nggak saling ganggu, kamu bisa lihat siapa yang habis paling banyak.
Nggak manfaatin cache hasil query. Snowflake nyimpen hasil query selama 24 jam. Query yang persis sama dan datanya belum berubah dijawab dari cache, gratis, tanpa nyalain warehouse. Jangan tambahin fungsi waktu saat ini ke query yang seharusnya bisa di-cache.
Nyalin data ke tabel baru terus-menerus. Pakai zero-copy cloning buat kebutuhan uji coba. Jauh lebih cepat dan nggak nambah biaya penyimpanan.
Nggak pasang batas pemakaian. Snowflake punya fitur resource monitor yang bisa ngasih peringatan atau matiin warehouse waktu kredit nyentuh batas tertentu. Pasang di awal, jangan nunggu tagihan datang.
Nggak jauh. Snowflake mengikuti standar ANSI SQL, jadi SELECT, JOIN, GROUP BY, CTE, dan window function jalan persis sama. Perbedaannya ada di beberapa nama fungsi tanggal, tipe data VARIANT untuk JSON, dan perintah khusus buat ngatur warehouse. Analis yang udah bisa PostgreSQL biasanya produktif di Snowflake dalam hitungan hari.
Tergantung banget pada pola pemakaian dan region. Tim berisi 3 sampai 5 analis dengan warehouse X-Small dan auto-suspend yang rapi biasanya cuma butuh puluhan sampai ratusan kredit per bulan. Harga per kredit dan biaya penyimpanan berbeda per edisi dan region, jadi cek halaman harga resmi buat angka yang berlaku di wilayah kamu.
Nggak. Snowflake dirancang biar nggak perlu ngatur index, partisi, atau tuning server. Analis bisa langsung nulis query lewat antarmuka web. Yang perlu kamu pelajari cuma konsep warehouse, struktur database dan schema, plus kebiasaan ngatur biaya.
Bisa. Snowflake punya konektor resmi buat berbagai tool, termasuk driver ODBC yang dipakai Excel dan koneksi ke tool dashboard seperti Tableau dan Power BI. Buat Google Sheets, biasanya lewat tool perantara atau ekspor hasil query.
Data lake nyimpen file mentah dalam berbagai format tanpa struktur ketat, biasanya murah tapi butuh usaha lebih buat dipakai. Snowflake nyimpen data dalam tabel terstruktur yang siap di-query pakai SQL. Snowflake juga bisa baca file di data lake lewat fitur tabel eksternal, jadi keduanya sering dipakai bareng.
Tiga hal yang perlu kamu bawa. Snowflake misahin penyimpanan dari komputasi, jadi biaya utamanya waktu warehouse nyala. Setel auto-suspend pendek dari hari pertama. Dan bikin tabel ringkasan buat dashboard, jangan biarin dashboard baca tabel mentah berulang kali.
Kalau kamu mau nyoba, Snowflake nyediain masa uji coba gratis dengan kredit awal. Cukup buat ngerasain alur kerjanya tanpa keluar biaya.
Mau nguatin SQL dulu sebelum masuk ke gudang data? Latihan interaktif ada di NgulikSQL. Baca juga soal ETL kalau kamu penasaran gimana data sampai ke gudangnya.
Mau praktek langsung? Mulai latihan SQL gratis
Latihan interaktif, langsung di browser.
Kolom waktu isinya angka gede kayak 1704067200 dan bikin bingung? Itu Unix timestamp. Ini cara ngubahnya jadi tanggal beneran di SQL, plus balik lagi.
Data transaksi tersimpan UTC, tapi laporan harus jam WIB. Kalau salah konversi, angka penjualan tengah malam bisa kecatat di tanggal yang salah. Ini cara handle timezone di SQL dengan benar.
Nambah 30 hari ke tanggal invoice, ngurangin sebulan buat cari periode lalu, ngitung selisih hari antar order. Semua itu aritmetika tanggal, dan SQL punya operator INTERVAL buat ngerjainnya.