Tagihan Sekitar 15 Juta

Tagihan bulan lalu masuk lewat email subuh. Sekitar Rp 15 juta. Bukan keluhan, juga bukan kebanggaan — itu sekadar harga dari satu sistem yang sudah lewat batas free tier.

Konteksnya: platform multi-tenant yang saya bantu rawat. Sekolah, dinas, beberapa UMKM — masing-masing punya subdomain sendiri, data sendiri, sebagian punya logic kustom sendiri. Mulanya satu Worker, satu D1, semua di plan gratis. Sekarang ratusan tenant, request bulanan jauh melewati batas Free.

Angka 15 juta itu juga sudah termasuk biaya untuk satu project lain yang belum bisa saya publikasi — masih ditutup, masih dalam pengembangan. Jadi tagihan ini menanggung dua beban: platform yang sudah jalan, plus satu eksperimen yang belum keluar.

Tiga komponen utama yang menyumbang tagihan: Workers Standard, Workers for Platforms, dan Postgres di Supabase.

---

Workers Standard — $5 per bulan base, plus usage. Saya pindah dari Free saat trafik tembus 10 juta request per bulan; di atas itu Free tidak lagi gratis, malah error. Yang membuat tagihan naik bukan request count semata, tapi CPU time. Beberapa endpoint berat — laporan agregat, render PDF, ekspor data — cepat memakan CPU-ms.

Pricing-nya transparan: $0.30 per juta request beyond included, $0.02 per juta CPU-ms beyond included. Itu yang saya hargai dari Cloudflare — angkanya tidak disembunyikan, dan billing dashboard menunjukkan breakdown per Worker, bukan satu lump sum.

Total Workers Standard duduk di kisaran $400–500 per bulan untuk volume saya saat ini.

---

Workers for Platforms — untuk multi-tenant. Awalnya semua logic ada di satu Worker dengan if-else per tenant. Saat tenant ke-50, kode jadi spaghetti — deploy satu fitur untuk satu tenant berisiko breaking yang lain.

WfP memberi namespace dispatch: setiap tenant punya script Worker sendiri di namespace yang sama. Saat request masuk, dispatcher routing ke script tenant yang tepat. Isolation real — satu tenant crash atau kena CPU limit tidak menyentuh tenant lain.

Pricing-nya beda dari Workers Standard: ada base $25 per bulan untuk dispatch namespace, plus per-script per-request rate. Volume saya menempatkan ini di sekitar $200–300 per bulan.

Pertanyaan yang sering muncul dari teman yang baru pertama dengar: "kenapa tidak satu Worker besar saja?" Jawaban-nya: kalau script tenant mau bisa di-update sendiri-sendiri tanpa redeploy seluruh platform, satu Worker bersama tidak bisa. WfP memungkinkan itu.

---

Supabase untuk Postgres. Ini pertama kalinya saya keluar dari Cloudflare dalam beberapa tahun.

D1 saya pakai untuk hal-hal sederhana: konten blog, registry kecil, data yang query-nya straightforward. Untuk platform multi-tenant dengan tabel puluhan ribu baris per tenant, full-text search untuk dokumen, dan beberapa stored procedure yang kompleks — Postgres lebih nyaman. Bukan karena D1 tidak bisa, tapi karena tooling Postgres (DBeaver, pgAdmin, ekosistem ekstensi) sudah saya pakai bertahun-tahun. Untuk kasus ini, saya pilih ergonomis daripada konsistensi vendor.

Supabase Pro ($25/bulan base) plus compute add-on untuk handle peak query — total sekitar $150–200 per bulan. Saya pakai connection pooler-nya (Supavisor) supaya Worker bisa connect tanpa exhaust connection limit, dan Storage untuk file yang butuh row-level access control yang ketat.

Latensi dari Worker (region SIN) ke Supabase (region Singapore) sekitar 3–5ms. Untuk request normal tidak terasa. Untuk request yang butuh 10+ query, saya pakai database function di Postgres — satu round-trip dari Worker, beberapa query di server.

---

Sisanya: R2 storage untuk arsip dan media (egress gratis itu pembeda terbesar dari S3), Stream untuk video pelatihan, Queues untuk job background. Masing-masing $30–80 per bulan. Total tagihan duduk di kisaran Rp 13–17 juta tergantung bulannya.

---

Pertanyaan yang sering muncul: "kenapa tidak migrasi ke VPS atau hyperscaler? 15 juta bisa dapat banyak server."

Jawaban-nya bukan harga absolut — yang saya dapat di setup ini adalah:

• Tidak ada server yang harus di-patch atau di-monitor sendiri
• Latensi global rata-rata di bawah 50ms tanpa konfigurasi apa pun
• Auto-scale tanpa harus pikir kapasitas
• Billing per komponen, bukan per server-jam

Untuk platform yang trafiknya didominasi user Indonesia tapi ada juga dari Malaysia dan Singapore, edge runtime memberi consistency yang sulit dicapai dari satu region VPS. Kalau saya pakai dua VPS region untuk replikasi yang sama, biaya sama tapi operasional jauh lebih berat.

---

Setup ini tidak cocok untuk semua orang. Kalau platform Anda:

• Trafiknya kecil (di bawah 5 juta request per bulan), Free tier Workers + D1 cukup
• Cuma satu tenant atau internal-only, Workers for Platforms berlebihan
• Query database sederhana, D1 atau Hyperdrive ke Postgres lebih murah dari Supabase

Saya pakai konfigurasi ini karena platform-nya sudah memenuhi tiga syarat: multi-tenant beneran, query Postgres berat, traffic nyata. Sebelum mencapai itu, lebih baik tetap di setup yang lebih sederhana. Jangan bayar Workers for Platforms hanya karena ingin namespace yang rapi — itu solusi untuk masalah skala, bukan estetika.

---

15 juta sebulan terdengar besar. Untuk satu platform yang melayani ratusan tenant aktif dengan uptime yang implicitly diharapkan, itu masih lebih murah dari satu engineer DevOps purnawaktu. Kalkulasi yang biasanya tidak diceritakan vendor — tapi kalau Anda yang bayar, perlu dihitung.

Yang berubah dari era VPS shared hosting: bukan total biaya — tapi biaya yang dikeluarkan akhirnya selaras dengan pengguna yang dilayani. Naik kalau lebih banyak, turun kalau sepi. Itu yang sulit didapat dari kontrak server bulanan.