Model harga cloud membebaskan kita dari belanja server di muka, tetapi imbalannya adalah tagihan yang bergerak sendiri: naik pelan-pelan mengikuti pemakaian, kadang melompat karena satu setelan yang terlewat. Mengelola biaya MongoDB Atlas menuntut pemahaman tentang komponen apa saja yang ditagihkan, cara mengukur kebutuhan dari data kita sendiri, dan kebiasaan memasang penjaga seperti tag project dan budget alert. Chapter ini menutup Section Deployment dan Cloud dengan perspektian biaya.

Komponen Biaya Atlas #

Tagihan Atlas disusun dari beberapa komponen yang bergerak independen. Mengenal satu per satu adalah syarat memahami kenapa tagihan bisa berubah:

KomponenDasar penghitunganCara menekan
Instance tierPer jam, sesuai tier cluster (M10, M30, dst.)Pilih tier terkecil yang lolos load test
StorageKapasitas disk per GB per bulanPantau pemakaian lewat db.stats()
BackupStorage snapshot dan masa simpan (retention)Singkat masa simpan untuk data tidak kritis
Transfer dataLalu lintas antar region dan egress ke internetSatukan region aplikasi dan cluster
Atlas SearchNode pencarian terpisah per jamHanya aktifkan bila fitur pencarian dipakai
FlexPer pemakaian dengan plafon bulananCocok untuk beban kecil-berfluktuasi

Cluster M0 tidak masuk tabel karena gratis — dengan batas keras sekitar 512 MB penyimpanan dan 500 koneksi bersama. Batas ini cukup untuk latihan dan prototipe, tetapi aplikasi dengan pengguna nyata akan menabraknya; hentikan pemakaian M0 sebelum data penting tumbuh melewati batas.

Mengukur Kebutuhan dari Data Sendiri #

Perkiraan storage tidak perlu ditebak. Perintah db.stats() melaporkan pemakaian nyata database kita — angka inilah yang dibandingkan dengan kapasitas disk yang dibayar. Kita ukur pada database uji kecil:

js
use latihan_biaya

Output yang Dihasilkan:

text
switched to db latihan_biaya
js
db.pelanggan.insertMany([
  { nama: "Budi", kota: "Bandung" },
  { nama: "Siti", kota: "Jakarta" },
  { nama: "Dewi", kota: "Surabaya" }
])
db.pelanggan.createIndex({ nama: 1 })

Output yang Dihasilkan:

text
{
  acknowledged: true,
  insertedIds: {
    '0': ObjectId('6ad3fc8bbc4702f1c29fdb15'),
    '1': ObjectId('6ad3fc8bbc4702f1c29fdb16'),
    '2': ObjectId('6ad3fc8bbc4702f1c29fdb17')
  }
}
nama_1
js
const s = db.stats()
printjson({
  jumlahDocument: Number(s.objects),
  dataByte: Number(s.dataSize),
  indexByte: Number(s.indexSize),
  totalByte: Number(s.totalSize),
  persenIndex: Math.round((Number(s.indexSize) / Number(s.totalSize)) * 100)
})

Output yang Dihasilkan:

text
{
  jumlahDocument: 3,
  dataByte: 166,
  indexByte: 24576,
  totalByte: 28672,
  persenIndex: 86
}

Empat angka di atas membawa pelajaran penting. dataSize adalah ukuran document murni (166 byte untuk 3 document), sedangkan indexSize adalah ukuran index — dan index di sini justru 86% dari totalSize. Pada database kecil, ukuran halaman minimum membuat index tampak raksasa; pada database produksi, porsi index biasanya puluhan persen. Kesimpulannya tetap sama: index ikut dibayar. Setiap index yang tidak dipakai query adalah storage (dan biaya) yang terbuang — audit daftar index seperti pada Chapter Deployment Checklist sebelum menaikkan kapasitas. Setelah selesai mengukur, kita bereskan jejaknya:

js
db.dropDatabase()

Output yang Dihasilkan:

text
{ ok: 1, dropped: 'latihan_biaya' }

Untuk memperkirakan kebutuhan produksi, jalankan pengukuran yang sama pada data staging yang volumenya mendekati nyata, lalu tambahkan ruang tumbuh beberapa bulan ke depan. Atlas juga menyediakan kalkulator biaya resmi yang menghitung estimasi bulanan berdasarkan tier, region, dan layanan tambahan yang dipilih.

Perkiraan Tier dan Biaya Tak Terduga #

Pemetaan kasar tier ke kebutuhan membantu memulai estimasi:

TierPerkiraan penggunaan
M0Belajar dan prototipe tanpa data berharga
FlexAplikasi kecil dengan beban naik-turun; plafon bulanan menjaga biaya
M10–M30Aplikasi produksi satu region dengan jutaan document
M50 ke atas / shardedBeban tinggi, data besar, atau kebutuhan multi-region

Beberapa lonjakan biaya yang paling sering mengejutkan: storage yang di-set otomatis menaik (autoscaling tanpa batas atas), masa simpan backup yang panjang untuk data yang sebenarnya tidak kritis, transfer data antar region karena aplikasi dan cluster berjauhan, dan naiknya tier secara otomatis saat beban puncak sementara. Kebiasakan penangkalnya: tetapkan batas atas autoscaling, tinjau retention backup setiap kuartal, samakan region aplikasi dan cluster, dan evaluasi apakah beban puncak lebih murah ditangani naik tier sementara atau dipecah.

Tag Project dan Budget Alert #

Dua penjaga terakhir bersifat administratif. Pertama, beri tag pada setiap project — misalnya env=prod atau tim=pembayaran — lewat pengaturan project atau flag --tag saat membuat cluster lewat CLI. Tag ini hadir pada laporan pemakaian, sehingga tagihan bisa dipilah per environment atau per tim; tanpa tag, semua biaya tampak sebagai satu gundukan.

Kedua, atur budget alert di pengaturan billing organization: Atlas mengirim email ketika pemakaian melewati ambang yang kita tentukan (misalnya 80% dan 100% anggaran bulanan). Kombinasi tag dan alert mengubah biaya dari kejutan bulanan menjadi sinyal yang bisa ditindaklanjuti — review singkat tiap awal bulan biasanya cukup untuk menjaganya tetap wajar.

Rangkuman #

  • Komponen tagihan: instance per jam, storage per GB, backup berdasarkan snapshot dan retention, transfer antar region, node Atlas Search, serta Flex berbasis pemakaian.
  • db.stats() mengukur kebutuhan dari data sendiri; ingat bahwa index ikut dibayar — di contoh kita 86% dari total pemakaian.
  • M0 gratis dengan batas keras 512 MB dan 500 koneksi; hentikan pemakaian sebelum data berharga menabrak batas.
  • Lonjakan tak terduga datang dari autoscaling tanpa plafon, retention backup panjang, dan region yang berjauhan — semua punya penangkalnya.
  • Tag project membuat biaya bisa dipilah per environment atau tim; budget alert mengubah kejutan menjadi sinyal dini.