Looker 150 Ribu Dolar vs HTML Statis: Biaya Dashboard 0,50 Dolar

Sebuah tim data platform berisi tiga engineer di perusahaan sekitar 500 orang mengganti sebagian fungsi Looker dengan layanan kecil yang menyajikan berkas HTML, dan delapan bulan kemudian pengeluaran mereka tercatat 8.300 dolar untuk periode itu, sekitar 12 kali lebih murah dibanding lisensi Looker rata-rata 150 ribu dolar per tahun untuk sekitar 300 seat. Angka itu datang dari catatan David Lequin pada 14 Oktober 2026, termasuk temuan bahwa satu dashboard memakan sekitar 1 juta token dan biayanya turun dari sekitar 2,50 dolar menjadi sekitar 0,50 dolar setelah pindah ke model yang lebih murah.

TL;DR

• Layanan HTML internal dibangun dalam satu sore pada Februari 2026 dan delapan bulan kemudian menyaingi jumlah pengguna mingguan Looker.
• Biaya satu dashboard turun dari sekitar 2,50 dolar menjadi sekitar 0,50 dolar karena harga token, bukan karena alatnya berubah.
• Total pengeluaran 8 bulan tercatat 8.300 dolar, dibanding lisensi Looker 150 ribu dolar per tahun.
• Looker tetap dipakai, tapi pemakaiannya turun sekitar sepertiga selama periode yang sama.
• Yang sebenarnya diganti bukan BI secara keseluruhan, melainkan bagian yang mengubah query menjadi gambar.

Berapa biaya sebenarnya untuk menggantikan Looker?

Delapan ribu tiga ratus dolar untuk delapan bulan, menurut rincian penulisnya. Angka itu mencakup seluruh biaya yang dikeluarkan tim untuk membangun dan menjalankan layanan HTML internal, dan dibandingkan dengan 150 ribu dolar per tahun untuk lisensi Looker rata-rata.

Yang membuat perbandingan ini masuk akal adalah konteks biaya token. Setiap dashboard memerlukan sekitar 1 juta token dari pertanyaan pertama sampai halaman selesai. Ketika harga token turun, biaya per dashboard ikut turun dari sekitar 2,50 dolar ke sekitar 0,50 dolar, meski pekerjaan yang dilakukan agen tetap sama. Penulisnya menyimpulkan bahwa membangun perangkat lunak sekarang biayanya mengikuti harga token, dan harga itu terus turun.

Tapi angka 8.300 dolar itu perlu dibaca dengan hati-hati. Biaya itu tidak memasukkan gaji tiga engineer yang membangun dan merawat layanan, tidak memasukkan waktu yang dipakai untuk menangani insiden, dan tidak memasukkan biaya infrastruktur yang sudah ada sebelumnya seperti Kubernetes dan Snowflake. Perusahaan itu sudah punya semua fondasi tersebut, sehingga biaya tambahannya kecil. Perusahaan yang belum punya fondasi serupa akan menghadapi angka yang berbeda.

Inilah kesalahan paling umum ketika membaca kisah seperti ini: mengambil angka akhirnya tanpa mengambil prasyaratnya. Perbandingan 12 kali lebih murah hanya berlaku di lingkungan yang sudah punya Kubernetes, SSO, penyimpanan objek, dan tim yang mampu merawat layanan kecil. Di lingkungan lain, biaya sebenarnya bisa jauh lebih tinggi, dan sebagian biaya itu muncul sebagai waktu engineer, bukan sebagai tagihan.

Bagaimana layanan itu dibangun dan dioperasikan?

Layanan itu menyimpan berkas HTML di penyimpanan objek, memasang SSO di depannya, dan dijalankan di Kubernetes yang sudah ada. Pembangunannya memakan waktu satu sore, dan penambahan fitur berjalan bertahap selama delapan bulan berikutnya.

Alurnya sederhana. Pengguna meminta analisis ke agen, agen menulis satu berkas HTML berisi grafik dan tabel, lalu skrip kecil mengunggah berkas itu ke penyimpanan dan mengembalikan tautan yang dilindungi SSO. Siapa pun di perusahaan bisa membuka tautan itu tanpa memasang alat baru. Pada bulan Maret, tim menambahkan API query langsung yang memakai token OAuth Snowflake milik penonton, sehingga halaman bisa menampilkan data terbaru tanpa disimpan ulang.

Pilihan teknis yang menarik di sini adalah tidak membangun aplikasi BI. Tidak ada semantic layer baru, tidak ada katalog metrik baru, dan tidak ada mesin visualisasi baru. Yang dibangun hanya tempat berbagi berkas dengan kontrol akses. Semua pekerjaan berat, yaitu menulis query dan memilih tampilan, diserahkan ke agen yang sudah dipakai perusahaan.

Konsekuensinya, kualitas hasil bergantung pada kualitas agen dan data yang bisa diaksesnya. Kalau agen salah menulis query, halaman yang dihasilkan terlihat meyakinkan tapi angkanya salah. Penulisnya menyebut hal ini secara eksplisit: SQL yang berjalan tanpa error tapi menghasilkan angka salah jauh lebih berbahaya daripada SQL yang gagal. Karena itu, kemampuan agen menjalankan query pemeriksaan sebelum menjawab menjadi penentu, bukan kemampuannya menulis kalimat yang terdengar pintar.

Bangun sendiri atau beli, mana yang lebih masuk akal?

Beli lebih masuk akal ketika kebutuhan utamanya tata kelola, konsistensi definisi metrik, dan dukungan vendor. Bangun sendiri masuk akal ketika kebutuhan utamanya kecepatan menjawab pertanyaan ad hoc, dan tim sudah punya fondasi data yang rapi.

Aspek	Looker dan BI komersial	HTML statis plus agen
Biaya lisensi	150 ribu dolar per tahun untuk sekitar 300 seat	8.300 dolar untuk 8 bulan pada kasus ini
Biaya per dashboard	Termasuk lisensi	Sekitar 0,50 dolar per halaman
Definisi metrik	Terpusat di semantic layer	Tersebar di prompt dan query
Kontrol akses	Bawaan, teruji	Harus dibangun sendiri di depan penyimpanan
Waktu membangun	Hitungan minggu untuk implementasi	Satu sore untuk versi awal
Risiko utama	Biaya dan adopsi rendah	Angka tidak konsisten antar halaman

Yang perlu digarisbawahi, penulisnya tidak mengklaim Looker sudah mati di perusahaannya. Looker masih dipakai, hanya pemakaiannya turun sekitar sepertiga sementara layanan HTML mengejar jumlah pengguna mingguan. Itu pola yang lebih realistis daripada cerita penggantian total: sebagian pekerjaan berpindah, sebagian tetap, dan keduanya hidup berdampingan.

Untuk perusahaan yang sedang mempertimbangkan langkah serupa, urutan yang masuk akal adalah memulai dari pertanyaan yang paling sering diajukan dan paling mahal dibuatkan dashboard-nya. Kalau pertanyaan itu berubah setiap minggu, pendekatan HTML lebih murah. Kalau pertanyaan itu stabil dan dipakai untuk keputusan rutin, semantic layer yang terpusat masih lebih baik karena definisi metriknya bisa diaudit.

Masalah apa yang muncul setelah dashboard dibuat agen?

Masalah utamanya bukan biaya, tapi konsistensi. Dua halaman yang dibuat pada hari berbeda bisa memakai definisi metrik yang sedikit berbeda, dan selisih kecil itu cukup untuk memicu perdebatan panjang di rapat.

Masalah kedua adalah kesegaran data. Halaman statis menampilkan angka pada saat dibuat. Kalau tidak ada mekanisme pembaruan, angka itu menua tanpa tanda apa pun, dan pembaca tidak tahu kapan terakhir diperbarui. Menambahkan API query langsung menyelesaikan sebagian masalah, tapi memindahkan beban ke sistem sumber dan menambah permukaan keamanan karena token pengguna dipakai di sisi halaman.

Masalah ketiga adalah kontrol akses. Menaruh berkas di penyimpanan objek dengan SSO di depan terdengar sederhana, sampai muncul pertanyaan tentang tautan yang sudah dibagikan ke orang yang salah, atau halaman yang berisi data departemen lain. BI komersial menyelesaikan ini lewat model izin berlapis yang sudah diuji bertahun-tahun. Layanan buatan sendiri harus membangun lapisan itu dari nol, dan biayanya muncul sebagai waktu engineering, bukan sebagai lisensi.

Masalah keempat adalah duplikasi. Tanpa katalog, orang membuat halaman baru untuk pertanyaan yang sudah pernah dijawab, karena tidak ada cara menemukan halaman lama. Dalam jangka panjang, biaya pencarian dan pemeliharaan bisa melampaui penghematan lisensi. Penulisnya menyebut hal ini sebagai bagian dari pekerjaan yang belum selesai, bukan sebagai masalah yang sudah terpecahkan.

Kapan pendekatan ini sebaiknya tidak dipakai?

Jangan dipakai ketika hasilnya menyangkut kepatuhan, audit eksternal, atau laporan keuangan yang harus bisa ditelusuri. Untuk keperluan itu, jejak definisi metrik dan kontrol perubahan lebih penting daripada kecepatan membuat halaman.

Pendekatan ini juga lemah untuk organisasi yang belum punya fondasi data yang bersih. Kalau tabel sumbernya sendiri tidak konsisten, agen akan mewarisi ketidakkonsistenan itu dan menyajikannya dengan tampilan yang meyakinkan. Kualitas keluaran agen tidak pernah melebihi kualitas data yang bisa diaksesnya.

Selain itu, hitung biaya perawatan sebelum memutuskan. Layanan kecil yang dibangun dalam satu sore tetap harus dirawat: pembaruan dependensi, penanganan insiden, rotasi kredensial, dan penambahan fitur. Kalau tidak ada orang yang bertanggung jawab, layanan itu akan membusuk, dan biaya membusuknya lebih mahal daripada lisensi yang dihemat.

Untuk pembanding open source, proyek seperti Apache Superset menawarkan jalur tengah: dashboard dengan semantic layer dan kontrol akses, tanpa lisensi per seat. Rincian harga Looker ada di halaman harga resminya, sementara kisah lengkap beserta angka biayanya ada di tulisan David Lequin.

Bagaimana mengukur apakah penghematan itu nyata?

Ukur empat hal: biaya lisensi yang benar-benar dihentikan, biaya token per halaman, jam engineering untuk perawatan, dan jumlah pengguna aktif mingguan. Tanpa keempatnya, penghematan hanya terlihat di satu sisi neraca.

Biaya lisensi hanya bisa dihitung sebagai penghematan kalau kontraknya benar-benar dipangkas atau tidak diperpanjang. Banyak perusahaan menambah tool baru tanpa mengurangi tool lama, sehingga biaya total justru naik meskipun biaya per dashboard terlihat murah. Perhatikan juga biaya transisi: migrasi dashboard lama, pelatihan pengguna, dan penulisan ulang dokumentasi.

Jam engineering adalah komponen yang paling sering hilang dari perhitungan karena tidak muncul di tagihan. Cara paling jujur adalah mencatat waktu yang dipakai untuk merawat layanan baru selama satu kuartal, lalu mengalikannya dengan biaya per jam tim. Kalau angka itu mendekati selisih lisensi, penghematannya bersifat semu.

Terakhir, ukur adopsi. Tool yang murah tapi dipakai sepuluh orang tidak menyelesaikan masalah yang sama dengan tool mahal yang dipakai tiga ratus orang. Yang layak dibandingkan adalah biaya per pengguna aktif dan biaya per keputusan yang diambil berdasarkan dashboard tersebut, bukan biaya per halaman.

FAQ

Apakah ini berarti BI komersial akan mati?

Tidak. Kasus ini menunjukkan sebagian pekerjaan berpindah ke halaman yang dibuat agen, sementara Looker tetap dipakai. Yang berubah adalah proporsi, bukan penggantian total, dan perusahaan itu masih mempertahankan tool lamanya.

Berapa biaya satu dashboard dengan pendekatan ini?

Sekitar 0,50 dolar per halaman pada kasus yang dilaporkan, setelah harga token turun dari sekitar 2,50 dolar. Angka itu hanya mencakup biaya token, belum termasuk infrastruktur, penyimpanan, dan waktu engineer.

Apakah datanya aman?

Keamanan bergantung pada lapisan yang dibangun sendiri: SSO, kontrol akses per berkas, dan pencatatan akses. Tanpa ketiganya, berkas HTML berisi data internal bisa tersebar lewat tautan yang dibagikan sembarangan.

Apakah perlu Kubernetes untuk memulai?

Tidak wajib. Penyimpanan objek plus SSO sudah cukup untuk versi awal. Kubernetes mempermudah deployment kalau perusahaan sudah memakainya, tapi bukan syarat, dan menambahkannya hanya untuk layanan ini justru menambah biaya operasional.