Sizing a VPS for a database server

Databases live and die on memory and disk I/O, so size for those first.

Memory. A database wants enough RAM to hold its hot working set (indexes and frequently-read rows) in cache; once it spills to disk, latency jumps. As a starting point:

• Small app database — HA-2G (2 GB) or HA-4G (4 GB)
• Busy production database — HA-8G (8 GB)
• Large or multi-tenant database — HA-16G (16 GB) or HA-32G (32 GB)

Disk. Every tier is NVMe, so random I/O is already fast. What varies is capacity. If your dataset is large — analytics, lots of history, big BLOBs — and outgrows the 100–300 GB on the HA tiers, use the HV-8G for its 1 TB of NVMe on the same 8 GB / 3 vCPU compute.

Cores. Two to three vCPU handle most transactional databases; go higher only if you run heavy concurrent queries or analytical workloads.

Because resources are dedicated under KVM, your query latency won't wobble with what other customers do — important for a database. And with no contract you can start conservative, watch cache-hit rates and memory pressure, and move up a tier if the working set outgrows RAM.