Memilih plan VPS bukan soal membeli angka sebesar mungkin sesuai budget — ini soal menyesuaikan CPU, RAM, dan NVMe dengan apa yang benar-benar dibutuhkan workload Anda, sehingga Anda membayar untuk kapasitas yang Anda pakai, bukan spesifikasi yang tidak Anda perlukan.
Tiga spesifikasi yang menentukan segalanya
Setiap plan VPS pada akhirnya adalah paket dari tiga resource plus jaringan. Pahami apa yang dikendalikan masing-masing, dan Anda bisa menentukan ukuran server yang tepat dalam waktu kurang dari satu menit.
vCPU
Berapa banyak pekerjaan yang berjalan paralel dan seberapa cepat. Menentukan throughput request, kompilasi, transcoding, dan segala sesuatu yang CPU-intensif.
RAM
Memori kerja. Database, cache, dan runtime aplikasi hidup di sini. Kalau habis, sistem akan swap ke disk atau kernel mematikan proses.
Penyimpanan NVMe
Kapasitas plus kecepatan. NVMe memberikan IOPS jauh lebih tinggi dibanding SATA SSD atau disk berputar — penting untuk database dan filesystem yang sibuk.
Bandwidth
Berapa banyak data yang bisa Anda pindahkan. Koneksi unmetered menghilangkan beban pikiran untuk terus memantau meteran traffic.
vCPU: jumlah core versus clock, dan mengapa sharing itu penting
vCPU adalah thread pada core fisik yang dialokasikan ke VM Anda. Dua plan bisa sama-sama menyebut "4 vCPU" tapi berperilaku sangat berbeda tergantung CPU host dan berapa banyak tetangga yang berbagi resource dengannya.
- Pekerjaan yang CPU-intensif (encoding video, build, batch job) skalanya mengikuti jumlah core dan clock speed — tambah core.
- Pekerjaan yang I/O-intensif (aplikasi web umum yang menunggu database atau jaringan) jarang membuat CPU jenuh — jangan beli core berlebihan.
- Beban 100% yang terus-menerus butuh core dedicated atau tidak berbagi; beban yang naik-turun (bursty) aman di core yang dishare.
- Menambah core tidak membuat proses single-threaded jadi lebih cepat — ini hanya membantu kalau workload Anda berjalan paralel.
Aturan praktis: kalau grafik CPU Anda jarang melewati 60% saat beban puncak, jumlah core Anda sudah cukup. Alihkan anggarannya ke RAM atau disk yang lebih cepat.
RAM: spesifikasi yang paling sering diremehkan
RAM adalah resource yang paling parah gagalnya kalau habis. Tekanan CPU hanya memperlambat Anda; tekanan memori memicu swapping dan out-of-memory killer, yang bisa membuat database offline di tengah query.
Database menyukai RAM karena mereka men-cache data yang sering diakses di memori alih-alih membaca dari disk. Kalau working set Anda muat di RAM, query tetap cepat; kalau harus meluber ke disk, latensi melonjak tajam.
Selalu sisakan ruang gerak. Menentukan RAM tepat sesuai puncak berarti lonjakan traffic pertama atau memory leak langsung mendorong Anda ke swap. Usahakan berjalan di 60-70% dari memori yang terpasang.
NVMe: kapasitas adalah setengah bagian yang mudah
Storage punya dua dimensi — seberapa banyak yang Anda simpan dan seberapa cepat Anda membaca serta menulisnya. NVMe menang telak di dimensi kedua, memberikan IOPS berkali-kali lipat lebih tinggi dibanding SATA SSD.
- Database, message queue, dan mail server sangat haus IOPS — NVMe menghilangkan disk sebagai bottleneck.
- Aplikasi yang banyak log atau banyak menulis diuntungkan oleh latensi tulis NVMe yang rendah.
- Untuk arsip dingin atau backup, kapasitas mentah lebih penting daripada kecepatan — plan storage lebih murah per GB.
- Tentukan kapasitas sesuai data Anda plus OS, swap, log, dan ruang untuk berkembang; disk yang terisi 100% membuat proses tulis korup.
Kalau Anda terutama butuh ruang besar untuk backup atau media, bukan I/O acak yang cepat, plan storage dedicated memberi Anda kapasitas tanpa harus membayar harga NVMe untuk seluruh volume.
Cara berulang untuk menentukan ukuran plan apa pun
- 1
Kenali workload-nya
Catat persis apa yang berjalan: aplikasi web, database, container, game server, VPN. Masing-masing punya profil resource yang berbeda.
- 2
Temukan resource yang jadi bottleneck
Tentukan apakah pekerjaan itu CPU-bound, memory-bound, atau I/O-bound. Resource itulah yang menentukan plan; sisanya cukup mengikuti.
- 3
Tentukan ukuran bottleneck dengan ruang gerak
Perkirakan permintaan puncak, lalu tambahkan sekitar 30-40% agar lonjakan dan pertumbuhan tidak memaksa migrasi darurat.
- 4
Seimbangkan sisanya
Sesuaikan spesifikasi lain agar tidak ada yang jadi bottleneck baru — core tanpa RAM, atau RAM tanpa NVMe, sama-sama membuang uang.
- 5
Mulai lebih kecil, skalakan berdasarkan data
Deploy, amati metrik nyata selama seminggu, lalu sesuaikan ukurannya. Angka yang terukur selalu mengalahkan tebakan.
Lokasi dan jaringan juga bagian dari spesifikasi
Server dengan ukuran paling pas pun tetap terasa lambat kalau lokasinya salah. Latensi ke pengguna Anda ditentukan oleh jarak fisik, jadi pilih data center yang dekat dengan audiens Anda — atau, kalau privasi jadi prioritas, satu yang berada di bawah yurisdiksi yang ramah privasi.
Di ChainVPS, setiap plan sudah dilengkapi bandwidth unmetered dan proteksi DDoS, tersedia di 15 lokasi dengan enam region privacy-tier — Belanda, Swiss, Rumania, Islandia, Moldova, dan Luksemburg. Kalau Anda ingin VPS offshore yang dibayar dari saldo prabayar kripto, kombinasi yurisdiksi dan pendaftaran tanpa KYC inilah alasan untuk mulai dari plan /offshore-vps.
Kesalahan umum dalam menentukan ukuran
Membeli banyak core untuk aplikasi I/O
Aplikasi web yang menunggu database-nya tidak akan memakai 8 core. RAM dan NVMe justru lebih membantu.
Tanpa ruang gerak RAM
Menentukan ukuran tepat sesuai puncak berarti lonjakan berikutnya langsung swap ke disk atau mematikan proses. Sisakan slack.
Mengabaikan kecepatan disk
Disk yang besar tapi lambat membuat database kelaparan. Sesuaikan IOPS dengan workload, bukan cuma gigabyte-nya.
Menebak alih-alih mengukur
Deploy secara buta membuang uang di dua arah. Metrik memberi tahu kebenarannya dalam seminggu.
Menyesuaikan jenis plan dengan pekerjaan
Begitu Anda tahu bottleneck-nya, tingkatan produk yang tepat akan mengikuti dengan sendirinya.
Kesimpulan utama: tentukan ukuran satu resource yang paling diandalkan workload Anda, jaga keseimbangan sisanya, sisakan ruang gerak, dan biarkan metrik nyata memandu upgrade pertama Anda.
Berapa banyak vCPU yang sebenarnya saya butuhkan?
Untuk sebagian besar aplikasi web dan database, 2-4 vCPU sudah lebih dari cukup karena pekerjaannya I/O-bound, bukan CPU-bound. Hanya workload paralel yang terus-menerus seperti transcoding atau kompilasi yang membenarkan penggunaan lebih banyak. Perhatikan grafik CPU Anda — kalau jarang melewati 60% saat puncak, jumlahnya sudah cukup.
Untuk database, lebih baik RAM lebih besar atau CPU lebih cepat?
RAM, di sebagian besar kasus. Database men-cache working set aktifnya di memori, jadi RAM lebih besar berarti lebih sedikit pembacaan disk yang lambat. Padukan RAM itu dengan penyimpanan NVMe, dan CPU jarang jadi batasan untuk beban query yang umum.
Apakah NVMe benar-benar penting, atau SSD apa pun sudah cukup?
Ini penting untuk apa pun yang I/O-intensif — database, mail, queue, log yang sibuk — karena NVMe memberikan IOPS jauh lebih tinggi dan latensi lebih rendah dibanding SATA SSD. Untuk backup dingin atau media yang cuma butuh kapasitas, volume yang lebih lambat dan lebih murah sudah cukup.
Haruskah saya over-provision demi keamanan?
Sisakan ruang gerak, tapi jangan beli berlebihan. Menentukan ukuran sekitar 60-70% dari kapasitas menyerap lonjakan tanpa harus membayar untuk resource yang menganggur. Mulai secara konservatif, amati metrik nyata selama seminggu, lalu sesuaikan ukurannya — Anda bisa top up saldo dan scale up kapan saja begitu data menunjukkan hal itu perlu.
