Membandingkan empat cloud data platform utama (BigQuery, Snowflake, Databricks, Redshift) dari sisi arsitektur dan model biaya, memahami peran managed services, lalu mempraktikkan proses evaluasi dan pemilihan platform

Setelah di episode 4 kita menentukan arsitektur (warehouse/lake/lakehouse), pertanyaan berikutnya: di platform mana arsitektur itu dibangun? Di sinilah keputusan arsitek menjadi sangat terasa oleh tim: platform menentukan bahasa SQL, tooling, cara biaya dihitung, dan bagaimana pipeline berjalan.
Mengapa episode ini penting? Karena pilihan platform adalah salah satu keputusan dengan lock-in paling kuat. Memindahkan data antar platform itu mudah; memindahkan tim, kode, dan operasional yang sudah terikat platform itu mahal. Arsitek harus menilai platform bukan dari fitur, tapi dari kecocokan dengan beban kerja, tim, dan biaya.
Warehouse serverless berbasis kolom: tidak ada server yang dikelola, compute dan storage terpisah. Kuat di analitik besar dengan kemampuan SQL yang sangat mumpuni, termasuk BigQuery ML untuk machine learning langsung dari SQL.
- Serverless: skala otomatis, tidak ada cluster yang di-provision
- Harga per TB query yang diproses + storage terpisah
- Integrasi mulus dengan GCP (Dataflow, Pub/Sub, Vertex AI)
- BigQuery Omni: query data di AWS/Azure tanpa pindahkanWarehouse terkelola multi-cloud (AWS/Azure/GCP) dengan pemisahan tiga lapis: storage, compute (virtual warehouse), dan services. Virtual warehouse bisa di-scale/suspend otomatis — kamu bayar hanya saat compute aktif.
- Multi-cloud: satu platform di AWS, Azure, dan GCP
- Virtual warehouse terpisah per workload, auto-suspend
- Zero-copy cloning & time travel bawaan
- Data sharing antar organisasi via Snowflake Secure Data SharingPlatform lakehouse berbasis open table format (Delta Lake) dengan engine Spark sebagai inti. Kuat untuk data engineering, machine learning, dan kini SQL via DBSQL. Berjalan di atas cloud mana pun (AWS/Azure/GCP).
- Lakehouse: Delta Lake di atas object storage kalian sendiri
- Spark sebagai engine komputasi (batch & streaming)
- Unity Catalog untuk governance terpusat
- Workspace notebook-first, kuat untuk data science & MLWarehouse managed berbasis cluster (PostgreSQL-like) dari AWS. Menawarkan harga kompetitif untuk beban BI berat, plus Redshift Spectrum untuk query langsung ke S3, dan Redshift Serverless untuk mode tanpa provisioning.
- Berbasis cluster; perlu tuning node & sort/dist keys
- Sangat terintegrasi dengan ekosistem AWS (S3, Glue, Athena)
- Redshift Serverless: compute otomatis, bayar per detik
- Murah untuk beban BI murni di AWS| Faktor | BigQuery | Snowflake | Databricks | Redshift |
|---|---|---|---|---|
| Cloud utama | GCP | Multi-cloud | Multi-cloud | AWS |
| Beban utama | SQL analytics | SQL analytics | Lakehouse + ML | SQL BI |
| Pengelolaan | Serverless | Managed | Managed | Cluster (perlu tuning) |
| Data lake format | Diintegrasikan | External tables | Delta (native) | Spectrum ke S3 |
| ML & AI | BigQuery ML | Snowpark ML | ✔ Paling kuat | Terbatas |
| Model biaya | Per TB query | Per second compute | Per unit DBU | Per node / per second |
Platform warehouse bukan satu-satunya komponen. Arsitek juga harus mempertimbangkan layanan terkelola di sekitarnya:
ingestion → AWS Glue / GCP Dataflow / Fivetran / Airbyte
orchestration → Apache Airflow (MWAA / Cloud Composer)
catalog → Datahub / OpenMetadata / Glue Catalog / Unity Catalog
monitoring → Data Quality dengan Great Expectations / dbt testsKeputusan di sini juga strategis: memilih orchestrator terkelola vs self-hosted menentukan siapa yang bertanggung jawab saat platform down di jam 3 pagi.
Ikuti proses evaluasi terstruktur — jangan pilih dari demo marketing:
kriteria bobot
kecocokan beban kerja 30
kemudahan operasional 20
biaya total (TCO) 20
integrasi ekosistem 15
skill tim & hiring 10
kematangan governance 5Buat proof of concept 1-2 minggu di masing-masing 2 platform kandidat dengan workload nyata:
# 1. Load dataset nyata (misal 100 GB) ke masing-masing platform
# 2. Jalankan 5 query yang mewakili workload harian
# 3. Catat: waktu, biaya per query, kerumitan tuning
# 4. Ukur waktu untuk menambahkan satu kolom + backfillUkur hal yang tidak ada di benchmark vendor: berapa lama tim kalian bisa men-debug query lambat, dan berapa biaya saat workload benar-benar berjalan 24/7.
Biaya bukan cuma tagihan platform. Hitung juga biaya tim, tooling, dan migrasi:
harga_platform = biaya storage + compute (aktif & idle)
harga_tooling = orchestrator, catalog, quality tools
biaya_tim = engineer yang harus dipelajari/di-hire
biaya_migrasi = mengubah pipeline & query yang ada
biaya_lock-in = kesulitan pindah di masa depanWarning
Jebakan umum: memilih platform dari harga per-query marketing tanpa menghitung compute idle. Warehouse yang selalu menyala 24/7 bisa menghabiskan puluhan kali biaya storage-nya. Selalu hitung skenario nyata: 24/7, business-hours only, dan burst — lalu bandingkan.
Tip
Di 2026 tren evaluasi mulai bergeser: alih-alih tanya "warehouse mana yang terbaik", organisasi bertanya "bagaimana platform ini mendukung open formats (Iceberg/Delta), AI workload, dan menghindari lock-in?" — karena tiga hal itu kini menjadi bagian dari biaya jangka panjang.
Inti yang harus dibawa pulang:
Di episode 6 selanjutnya kita akan membahas Data Pipeline Architecture — batch vs streaming, peran orchestration dengan Airflow, dan pola pipeline yang sehat untuk produksi. Sampai jumpa di episode 6!