karawaci.kode

2026-08-17 · 10 min

Self-Hosting vs Managed Service: Hitung Biaya dan Risiko Vendor Lock-in

Di hari kemerdekaan ini saya ingin menulis tentang kemerdekaan yang lebih konkret: bebas dari ketergantungan vendor yang sewaktu-waktu bisa naik harga atau tutup. Pertanyaannya bukan apakah self-hosting lebih “bebas” — itu retorika. Pertanyaannya adalah: berapa biaya nyata kemerdekaan itu, dan apakah worth it untuk situasi kamu sekarang.

Konteks: Kapan Ini Jadi Masalah

Lock-in vendor menjadi masalah nyata di tiga momen: saat vendor naik harga signifikan (Heroku 2022, PlanetScale shutdown free tier 2024), saat fitur yang kamu andalkan deprecated, atau saat compliance/audit memaksa data berada di lokasi tertentu. Di Indonesia, klien enterprise sering terhantam sisi ketiga — regulasi OJK dan BI mengharuskan data keuangan berada di dalam negeri, sedangkan mayoritas managed service tidak punya availability zone di Indonesia.

Dua kubu yang biasanya berhadapan:

  • Managed service: bayar lebih mahal, dapat SLA, tidak perlu urus infrastruktur
  • Self-hosting: bayar server saja, tapi semua operasional di tangan sendiri

Kenyataannya lebih nuansa dari itu. Mari hitung angka sebenarnya.

Kalkulasi Biaya: Studi Kasus PostgreSQL

Ambil contoh konkret: PostgreSQL production untuk aplikasi SaaS dengan 50GB data, 200 koneksi concurrent, satu read replica.

Opsi A — Managed (Neon/Supabase):

Neon Business plan       : $69/bulan (8 GB RAM, auto-scaling compute)
Supabase Pro             : $25/bulan + $0.125/GB storage
  → 50GB storage         : $25 + $6.25 = $31.25/bulan

Di angka ini managed service jauh lebih murah dari yang kebanyakan engineer kira.

Opsi B — Self-hosted di Hetzner:

CPX31 (4 vCPU, 8 GB RAM)  : €15.90/bulan ≈ $17/bulan
CX22 untuk replica         : €7.49/bulan  ≈ $8/bulan
Volume 100GB (storage SSD) : €4.48/bulan  ≈ $5/bulan
Backup ke S3 (Hetzner OBS) : ~$2/bulan
Total server               : ~$32/bulan

Harga server hampir sama. Tapi ini belum termasuk biaya engineer.

Setup awal (HA setup, PgBouncer, backup script, monitoring):
  → Estimasi 16 jam × $50/jam = $800 one-time

Maintenance rutin per bulan:
  → Patching, upgrade versi minor, cek backup: ~3 jam/bulan
  → 3 × $50 = $150/bulan

On-call overhead (insiden rata-rata 1x/bulan, 1 jam):
  → $50/bulan

Artinya biaya nyata self-hosting untuk PostgreSQL skala ini:

$32 (server) + $150 (maintenance) + $50 (on-call) = $232/bulan
+ amortisasi setup: $800 / 24 bulan = $33/bulan
= ~$265/bulan efektif

Versus Supabase Pro $31/bulan. Selisihnya $234/bulan, atau hampir $2.800/tahun — hanya untuk PostgreSQL. Managed service jelas menang di skala ini.

Perhitungan mulai berbalik saat workload tumbuh. Simulasi untuk 500GB data, 1000 koneksi:

Supabase Pro + add-ons   : ~$200-350/bulan (compute + storage)
Neon Business scale-up   : $200+/bulan

Self-hosted Hetzner:
  CPX51 (16 vCPU, 32GB)  : ~$60/bulan
  2 replicas (CPX31 ×2)  : ~$34/bulan
  Storage 1TB volume      : ~$45/bulan
  Total server            : ~$139/bulan
  + maintenance (sama)    : $200/bulan efektif

Di titik ini selisihnya mengecil. Kalau tim sudah punya DevOps dedicated, break-even ada di kisaran $500/bulan total cost managed service.

Redis: Kasus yang Lebih Sederhana

Redis lebih mudah dikalkulasi karena operasionalnya lebih ringan dari PostgreSQL.

# docker-compose untuk self-hosted Redis dengan Sentinel
version: '3.8'
services:
  redis-master:
    image: redis:7.4-alpine
    command: >
      redis-server
      --requirepass ${REDIS_PASSWORD}
      --maxmemory 2gb
      --maxmemory-policy allkeys-lru
      --save 60 1000
      --appendonly yes
    volumes:
      - redis-data:/data
    deploy:
      resources:
        limits:
          memory: 2.5G

  redis-sentinel-1:
    image: redis:7.4-alpine
    command: >
      redis-sentinel /etc/redis/sentinel.conf
    volumes:
      - ./sentinel.conf:/etc/redis/sentinel.conf
# sentinel.conf minimal
sentinel monitor mymaster redis-master 6379 2
sentinel auth-pass mymaster ${REDIS_PASSWORD}
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000

Biaya Upstash Redis (managed, serverless) untuk 100 juta command/bulan: sekitar $20-40/bulan. Self-hosted di server yang sama dengan app server (shared): hampir nol tambahan. Self-hosted di instance dedicated: $8-15/bulan server + overhead operasional.

Untuk Redis, self-hosting jauh lebih masuk akal karena kompleksitas operasionalnya rendah, ekosistemnya stabil, dan worst-case failure-nya lebih mudah ditangani. Saya selalu anjurkan self-hosting Redis kecuali kamu pakai edge functions atau serverless yang tidak bisa maintain koneksi persisten — di situlah Upstash masuk akal secara arsitektur, bukan karena biaya.

Monitoring Stack: Grafana vs Datadog

Ini kasus paling ekstrem kontrasnya.

Datadog APM + Logs + Metrics (20 host, 15GB logs/bulan):
  → $23/host/bulan × 20 = $460
  → Logs ingestion: 15GB × $0.10/GB = $1.50/bulan... 
     tapi retensi 7 hari: $1.8/GB/bulan × 15GB = $27
  → APM Traces: ~$100-200/bulan
  Total: $600-700/bulan
Self-hosted Grafana + Loki + Tempo + Prometheus:
  Server 2 CPX31 (dedicated observability): ~$34/bulan
  Object storage untuk log (Hetzner OBS): ~$10/bulan
  Total server: ~$44/bulan
  + setup dan maintenance: $100-150/bulan efektif

Selisihnya $450-600/bulan. Untuk ini, self-hosting hampir selalu menang di atas skala startup kecil. Setup Grafana stack untuk production memang butuh effort — sekitar 20-30 jam pertama kali — tapi setelah jalan, maintenance-nya rendah. Saya sudah deploy stack ini untuk beberapa klien Tangerang dan Jakarta, dan setelah stabil, practically maintenance-free kecuali upgrade major.

# Quickstart Grafana stack dengan docker compose
git clone https://github.com/grafana/docker-otel-lgtm
cd docker-otel-lgtm

# Edit .env untuk production
cat >> .env << 'EOF'
GF_SECURITY_ADMIN_PASSWORD=your-strong-password
GF_SERVER_DOMAIN=grafana.yourdomain.com
LOKI_RETENTION_PERIOD=30d
EOF

docker compose up -d

Risiko yang Sering Diabaikan

Biaya bukan satu-satunya dimensi. Ada risiko asimetris di kedua sisi:

Risiko managed service:

  • Vendor naik harga atau tutup layanan (PlanetScale, Heroku menjadi preseden)
  • Data berada di yurisdiksi asing — masalah untuk regulated industry
  • Outage vendor tidak bisa kamu mitigasi; kamu hanya bisa menunggu
  • Fitur proprietary yang tidak ada padanannya membuat migrasi sangat mahal

Risiko self-hosting:

  • On-call burden jatuh ke tim kamu — insiden jam 3 pagi adalah kamu yang tanggapi
  • Security patching harus aktif dipantau — CVE PostgreSQL atau Redis tidak auto-apply
  • Backup dan disaster recovery sepenuhnya tanggung jawab kamu
  • Skill gap: kalau engineer yang setup keluar, pengetahuan bisa ikut pergi

Untuk database production klien fintech kami, saya pilih model hybrid: database di managed service (Neon atau Supabase, karena compliance dan backup garantinya jelas) tapi Redis, queue (NATS/RabbitMQ), dan monitoring self-hosted. Ini bukan karena ideologi, tapi karena kalkulasi risk-adjusted cost-nya masuk akal.

Framework Keputusan

Sebelum memilih, jawab empat pertanyaan ini:

1. Seberapa besar dampak downtime layanan ini?
   Tinggi (revenue langsung) → managed service, SLA eksplisit
   Rendah (internal tooling) → self-hosting

2. Apakah ada compliance/data residency requirement?
   Ya → self-hosting atau managed dengan AZ Indonesia
   Tidak → bebas pilih

3. Apakah tim punya kapasitas operasional?
   Tim DevOps dedicated → pertimbangkan self-hosting untuk cost besar
   Tim kecil (< 5 engineer) → managed service hampir selalu lebih hemat

4. Berapa total tagihan managed service per komponen?
   < $100/bulan → managed service lebih murah secara total
   $200-500/bulan → evaluasi serius self-hosting
   > $500/bulan → self-hosting perlu dianalisis detail

Strategi Mitigasi Lock-in Tanpa Full Self-Hosting

Kalau kamu tidak mau repot self-hosting tapi khawatir lock-in, ada middle ground: arsitektur yang portable.

// Jangan ini — langsung coupling ke SDK spesifik di seluruh codebase
import { createClient } from '@supabase/supabase-js';
const supabase = createClient(url, key);
const { data } = await supabase.from('users').select('*');

// Lakukan ini — abstraksi repository di belakang interface
interface UserRepository {
  findById(id: string): Promise<User | null>;
  save(user: User): Promise<void>;
}

// Implementasi bisa swap tanpa mengubah domain logic
class PostgresUserRepository implements UserRepository {
  constructor(private db: Pool) {} // Pool dari 'pg' — standar, bukan proprietary

  async findById(id: string): Promise<User | null> {
    const result = await this.db.query(
      'SELECT * FROM users WHERE id = $1',
      [id]
    );
    return result.rows[0] ?? null;
  }
}

Dengan repository pattern, pindah dari Supabase ke Neon ke self-hosted PostgreSQL hanya butuh ganti implementasi satu file, bukan refactor seluruh codebase. Ini bukan over-engineering — ini asuransi migration yang murah.

Verdict

Self-hosting bukan jawaban untuk semua masalah, dan managed service bukan pemborosan. Kalkulasinya tergantung skala dan kapasitas tim.

Rekomendasi konkret berdasarkan pengalaman lapangan:

  • Database utama (PostgreSQL): managed service sampai tagihan menyentuh $200+/bulan atau ada compliance issue. Di bawah itu, biaya engineer untuk self-hosting lebih mahal dari selisihnya.
  • Redis/cache: self-hosting, kecuali arsitektur serverless/edge. Operasionalnya rendah dan hematnya signifikan.
  • Message queue: self-hosting NATS atau RabbitMQ — managed queue (SQS, Google Pub/Sub) mahal di volume tinggi dan sulit diprediksi tagihannya.
  • Monitoring/observability: self-hosting Grafana stack setelah tagihan Datadog/New Relic menyentuh $200/bulan. ROI-nya paling cepat di antara semua kategori.
  • Auth: managed (Clerk, Auth0) hampir selalu lebih murah secara total cost. Edge case: kalau butuh custom flow yang managed service tidak support.

Yang paling penting: apapun yang kamu pilih, dokumentasikan migration runbook-nya. Kemerdekaan dari vendor lock-in bukan soal tidak pakai managed service sama sekali — tapi soal memastikan kamu bisa pindah kapanpun ada alasan yang cukup kuat untuk itu.

Ditulis oleh Reza Pradipta