Silakan, host Postgres sendiri

• Self-hosting Postgres tidak rumit atau berisiko, dan merupakan pendekatan yang lebih murah daripada layanan terkelola serta lebih bebas untuk tuning performa
• Sebagian besar layanan database cloud dijalankan dalam bentuk Postgres open source yang sedikit dimodifikasi, dan perbedaan nyatanya ada pada tingkat otomatisasi operasional
• Dalam kasus operasi nyata, Postgres self-hosted mampu menangani ribuan pengguna dan puluhan juta query secara stabil dengan waktu pemeliharaan yang sangat kecil
• Karena kenaikan harga layanan terkelola seperti AWS RDS, kini memungkinkan menjalankan server dengan spesifikasi jauh lebih tinggi sendiri dengan biaya yang sama
• Bagi tim skala menengah yang pengelolaan infrastrukturnya tidak terlalu kompleks, self-hosting menjadi alternatif realistis dari sisi efisiensi biaya dan performa

---

Perubahan narasi yang berpusat pada cloud

• Di masa lalu, sebagian besar perusahaan mengoperasikan database langsung di server sendiri, dan ini merupakan arsitektur yang cepat dengan latensi jaringan rendah
  • Pada era 1980~2000-an, server aplikasi dan server database sering berada pada perangkat fisik yang sama
• Peluncuran Amazon RDS (2009) diterima sebagai tawaran menarik yang mengotomatisasi backup, patching, dan monitoring
  • Pada awalnya, beban operasional bisa dikurangi dengan harga yang mirip dengan server dedicated
• Sejak 2015, ketika adopsi cloud makin cepat, muncul pandangan bahwa mengelola infrastruktur sendiri itu tidak efisien
  • Model di mana AWS mengelola infrastruktur dan developer fokus pada logika aplikasi menjadi standar
• Pada 2025, harga RDS naik signifikan, sehingga dengan biaya yang sama kini bisa menyewa server dedicated dengan spesifikasi jauh lebih tinggi
  • Contoh: instance db.r6g.xlarge (4 vCPU, 32GB RAM) seharga $328 per bulan, setara dengan sewa server 32 core · 256GB RAM

Komposisi nyata layanan terkelola

• AWS RDS pada dasarnya adalah Postgres standar dengan tambahan sistem monitoring dan backup khusus AWS
  • Termasuk backup berbasis snapshot EBS, configuration management melalui Chef/Puppet/Ansible, connection pooling dengan PgBouncer, monitoring CloudWatch, dan skrip failover otomatis
• Susunan ini secara teknis tidak terlalu rumit, dan nilai utamanya adalah otomatisasi operasional serta kemudahan deployment awal
• Hasil migrasi dari RDS ke self-hosting dengan server spesifikasi setara menunjukkan performa setara atau bahkan meningkat
  • Parameter yang dibatasi di RDS bisa diatur langsung sehingga optimasi performa dimungkinkan

Kompleksitas operasional self-hosting

• Migrasi ke server DigitalOcean 16 vCPU / 32GB RAM / disk 400GB memakan waktu sekitar 4 jam, lalu terbukti stabil dalam operasi berikutnya
• Lini produk high availability memerlukan waktu administrasi sekitar 30 menit per bulan, sedangkan layanan dengan trafik rendah dapat sepenuhnya diotomatisasi
• Siklus pengelolaan rutin
  • Mingguan (10 menit) : verifikasi backup, meninjau slow query log, memeriksa kapasitas disk
  • Bulanan (30 menit) : update keamanan, memeriksa kebijakan retensi backup, capacity planning
  • Triwulanan (2 jam) : memperbarui dashboard monitoring, optimasi konfigurasi, uji pemulihan
• Penanganan insiden menjadi tanggung jawab sendiri, tetapi RDS juga bisa mengalami gangguan dan pada akhirnya developer tetap harus merespons
• Saat mengelola sendiri, waktu update dan zona risiko bisa diatur sendiri, sehingga lebih mudah menjaga stabilitas

Kapan self-hosting tidak cocok

• Saat developer tahap awal perlu membuat prototipe dengan cepat, layanan terkelola lebih praktis
• Perusahaan besar mungkin lebih efisien menempatkan database engineer khusus, atau mendelegasikan ke cloud untuk mengurangi biaya tenaga kerja
• Industri yang teregulasi (PCI-DSS, HIPAA, dll.) mungkin mensyaratkan penggunaan platform terkelola yang tersertifikasi

Poin konfigurasi utama

• Pengaturan memori: perlu menyesuaikan shared_buffers, effective_cache_size, work_mem, maintenance_work_mem, dan lainnya dengan hardware
  • Contoh: shared_buffers disetel ke 25% RAM, effective_cache_size ke 75%
• Manajemen koneksi: gunakan pgbouncer untuk connection pooling, bekerja efisien di lingkungan Python asyncio
  • Contoh konfigurasi dasar seperti max_connections = 200, log_connections = on
• Tuning storage: pada lingkungan NVMe SSD, sesuaikan random_page_cost = 1.1, effective_io_concurrency = 200, dan seterusnya
  • Kecepatan baca acak meningkat sehingga query planner dapat dioptimalkan
• Pengaturan WAL: sesuaikan wal_level = replica, max_wal_size = 2GB, checkpoint_completion_target = 0.9, dan lainnya untuk daya tahan dan performa

Kesimpulan

• Tidak semua infrastruktur perlu dikelola sendiri, tetapi Postgres termasuk area yang masuk akal untuk self-hosting
• Jika saat ini menghabiskan lebih dari $200 per bulan untuk RDS, layak mencoba memindahkan database nonkritis ke server uji
• Ke depan, infrastruktur kemungkinan berkembang ke bentuk hybrid antara layanan terkelola dan self-hosting
• Postgres dinilai sebagai kandidat self-hosting dengan efisiensi biaya yang tinggi

[yangeok]

Karena storage-nya juga menjamin 11 nines, pengelolaannya jadi sulit kalau dipakai seperti memakai cloud, makanya pakai cloud saja, hehe

[kaydash]

Sebenarnya, mengoperasikan klaster 3 node tidak akan semudah itu.

[GN⁺]

Komentar Hacker News

• Saya melihat self-hosting sebagai persoalan tanggung jawab
  Saya meng-host sendiri beberapa produk SaaS, biayanya jauh lebih murah daripada AWS dan performanya juga jauh lebih baik
  Namun untuk proyek klien, saya tetap meyakinkan mereka untuk membayar AWS. Karena dengan begitu tanggung jawab atas ketersediaan hardware bisa dialihkan ke pihak lain
  Kalau anggaran terbatas, biaya RDS terasa memberatkan. Menjalankan cluster Galera 3 node di Hetzner dengan beberapa dolar jauh lebih ekonomis
  Tetapi layanan terkelola seperti Cloudflare atau SQS juga kadang mengalami gangguan. Pada akhirnya, stabilitas sempurna memang tidak ada di mana pun

  • Saya pernah bertanya, “Kenapa pindah dari NoNameCMS ke Salesforce?”, dan jawabannya adalah, “Kalau Salesforce down, itu bisa masuk berita di WSJ.” Itu alasan yang sangat nyata untuk melempar tanggung jawab
  • Dari sudut pandang pelanggan klien, argumen seperti “Ikea dan Disney juga pernah down” tidak ada artinya. Yang penting bagi mereka hanyalah layanan mereka sendiri berhenti
  • Ada AWS Serverless PG, jadi tidak ada alasan kuat untuk repot mengelolanya sendiri. Untuk trafik rendah, biayanya nyaris gratis, dan jauh lebih unggul dari sisi keamanan, backup, dan integrasi
    AWS Aurora Serverless
  • Ada juga jalan tengah: outsourcing hanya sampai level VM, lalu sisanya dikelola sendiri. Ini tergantung pada overhead operasional dari stack teknologi yang dipakai
  • Selama 20 tahun saya mengelola SQL self-hosted milik banyak klien, dan belum pernah sekali pun ada server SQL yang down
    SQL cloud justru punya struktur biaya yang rumit, dan kalau backup sudah dikonfigurasi sekali, ya selesai

• Saya tidak setuju dengan klaim bahwa self-hosting adalah pilihan yang cocok untuk kebanyakan orang
  Menurut saya, itu baru masuk akal kalau anggarannya ketat, atau kalau skalanya sudah cukup besar untuk punya engineer khusus
  Untuk perusahaan kecil, menyerahkan ke cloud lebih realistis. Setelah setup, hitungannya cukup 30~120 menit pengelolaan per bulan

  • Sebagian besar perusahaan tetap mempekerjakan infra engineer meskipun memakai cloud. Gagasan bahwa “cloud mengurangi biaya tenaga kerja” itu tidak benar
    PaaS seperti Heroku atau Render memang bisa ditangani developer biasa, tetapi harganya jauh lebih mahal
    Pada akhirnya, kalau pemulihan aplikasi belum diotomatisasi, tetap saja Anda akan terbangun jam 3 pagi
  • Sebagian besar layanan tidak membutuhkan high availability. Kalau down hari Sabtu, bisa diperbaiki hari Senin
    Kalau itu tool internal, menambahkan satu Postgres ke Docker cuma butuh 5 menit
  • Cloud juga tetap butuh 1~2 jam pengelolaan per bulan. Tidak jauh berbeda dengan self-hosting
  • Kalau pakai RDS, justru visibilitas dan kendali berkurang sehingga debugging jadi lebih sulit
  • Inti persoalannya bukan efisiensi, melainkan siapa yang akan kena omel saat ada masalah. Kalau pakai cloud, tanggung jawab lebih mudah dialihkan

• Definisi ‘database terkelola’ terasa membingungkan
  Bagi saya, syarat dasarnya adalah backup otomatis, optimasi indeks, failover lintas multi-datacenter, point-in-time recovery, analisis slow query, dan prediksi storage
  Kalau semua itu disediakan dalam biaya bulanan, perdebatan soal self-hosting jadi tidak terlalu berarti

  • Masalahnya adalah kita harus mempekerjakan tenaga ahli. Kalau orang yang menangani Postgres sedang cuti, muncul masalah bus factor
    Akhirnya Anda menempatkan dua orang, lalu karena pekerjaannya terlalu sepi, mereka mencoba perbaikan yang tidak perlu dan malah menghabiskan 6 bulan
  • Alasan utama self-hosting pada akhirnya adalah latensi. Backup atau analisis itu hal dasar, dan kalau dibangun sendiri biasanya bisa paling cepat
  • Kalau setup-nya benar, hal seperti backup atau failover multi-region juga bisa diotomatisasi
  • Saya hanya melakukan self-hosting untuk layanan yang tidak akan menelepon saya jam 3 pagi. Untuk log atau analitik internal, masih oke, tapi DB jelas bukan
  • Yugabyte open source mencakup sebagian besar fitur-fitur ini

• DB terkelola terlalu mahal dibanding VPS
  Saya sempat berharap ada premium yang wajar untuk kemudahan, tapi kenyataannya harganya bisa berkali-kali lipat. Karena itu saya tidak memakainya kecuali untuk proyek besar

  • Mereka membuat Anda percaya bahwa Anda tidak mampu melakukannya sendiri, lalu terus menaikkan harga. Karena Anda tidak punya kemampuan untuk pindah, akhirnya jadi terkunci

• Bagian soal high availability (HA) yang disebut di artikel terasa kurang. Konfigurasi WAL saja tidak cukup untuk menjelaskannya. Replikasi itu mahal

• Saya tidak mengerti kenapa Postgres begitu dilebih-lebihkan di HN
  Tidak ada cara yang mudah untuk membangun cluster HA dengan failover otomatis seperti MongoDB. Saya penasaran bagaimana ini diselesaikan di layanan produksi

  • Komunitas PostgreSQL juga menyadari masalah ini. Mereka iri pada keandalan replikasi bawaan milik MongoDB
    Diskusi terkait: mailing list PostgreSQL
  • Jika memakai Kubernetes, CloudNativePG pada praktiknya adalah solusi HA standar
  • Di dunia SQL, mereka lebih terbiasa dengan pemulihan cepat (Disaster Recovery) ketimbang HA yang sesungguhnya
    Dalam praktiknya, semua koneksi akan terputus, cache akan diinisialisasi ulang, dan saat upgrade, downtime layanan tidak terhindarkan
    Hanya Oracle RAC yang menjadi pengecualian, dan PostgreSQL memang bukan dirancang seperti itu. YugabyteDB setidaknya bisa menjadi alternatif
    Sebagian besar aplikasi menoleransi downtime beberapa jam. Hanya perusahaan besar yang mampu menanggung otomasi yang kompleks
  • Cara yang paling umum adalah memakai Patroni. Kalau ingin lebih sederhana, gunakan Autobase
    Untuk lingkungan Kubernetes, CloudNativePG juga bagus.
    pg_auto_failover sederhana, tetapi ada keterbatasannya
  • Sebenarnya, sebagian besar bisnis memang tidak membutuhkan HA serumit itu. Imbal hasil dibanding biayanya rendah

• Melihat Autobase, tampaknya ia mengotomatiskan pekerjaan yang dibutuhkan saat self-hosting

  • Saya sudah melihat sekilas README-nya, dan sepertinya connection pooling berada di luar cakupannya
  • Saya penasaran apakah ini juga terintegrasi dengan baik dengan PaaS self-hosted lain. Kelihatannya berjalan dalam bentuk container Docker
  • Proyek yang keren, terima kasih

• Selama 15 tahun saya selalu memakai Postgres self-hosted, dan hampir tidak pernah mengalami masalah
  Satu-satunya kerepotan adalah saat harus melakukan migrasi versi PG agar cocok dengan upgrade ORM. Itu bisa diatasi dengan administrasi sistem yang hati-hati

• Saya pernah menjalankan Postgres non-terkelola sendiri di Fly.io, dan itu benar-benar menyiksa
  Node sering mati sehingga saya harus memulihkannya manual dengan repmgr, dan akhirnya saya mendokumentasikan prosedurnya di wiki internal
  Tujuan cluster itu high availability, jadi saya tidak paham kenapa zombie primary tidak ditangani otomatis
  Pada akhirnya saya pindah ke Postgres terkelola, dan sangat nyaman karena saat ada gangguan, ada orang lain yang menanganinya

  • Sekarang saya memakai Managed Postgres dari Fly

• Banyak komentar di thread ini mengabaikan faktor dunia nyata seperti skala, beban kerja, tenaga kerja, waktu, tahap bisnis, dan kebutuhan skalabilitas
  Bisa jadi self-hosting cocok, bisa juga tidak, tetapi diskusinya terlalu disederhanakan

  • Engineer cenderung hampir tidak mempertimbangkan faktor-faktor itu, dan malah memilih solusi paling mahal yang kemungkinan besar akan disetujui atasan

[sinbumu]

Bagi para developer, kekhawatirannya mungkin juga soal apakah upaya seperti itu akan diakui saat melakukan self-hosting. Meski biaya cloud lebih besar, kalau penghematan biaya lewat self-hosting tidak diakui, rasanya lebih mudah pakai layanan cloud saja dan menutupinya sambil mengurangi area yang harus ditangani.