Self-managed database best practices: VPS or Dedicated for your database
Quick answer
A VPS is enough for light-to-moderate database workloads: development, staging, and applications where the database isn't the bottleneck. Move to Bare Metal Compute or a Dedicated Server once the database is I/O-heavy and latency-sensitive in production, has a working set too large to sit comfortably in shared virtualised RAM, or is regularly affected by CPU steal time. This article covers self-managed databases you run and administer yourself on Worldstream's compute products, not a managed database service.
When a VPS is enough
Plenty of databases run perfectly well on a VPS. If any of these describe your situation, a VPS is a reasonable starting point rather than something to grow out of immediately:
- Light-to-moderate workloads. Query volume and concurrency are modest enough that CPU and storage aren't consistently pushed near their limits.
- Development and staging environments. These exist to test and iterate, not to serve production traffic, so the isolation and raw I/O guarantees that matter in production matter less here.
- Applications where the database isn't the bottleneck. If your application is limited by something else entirely (external API calls, application logic, network latency to third parties), a faster database tier won't move the needle.
When to move to Bare Metal Compute or a Dedicated Server
Certain patterns are a reliable signal that a database has outgrown shared virtualised infrastructure:
- I/O-heavy production databases needing consistent low-latency storage. On shared infrastructure, storage is a resource other tenants also draw on. A database that depends on predictable, low-latency reads and writes is exactly the workload most exposed to noisy-neighbour contention on shared storage.
- Working sets larger than what's comfortable on shared virtualised RAM. If your database's active working set barely fits, or doesn't fit, in the RAM available on a VPS tier, you're paying a performance cost in cache misses and disk reads that a larger, dedicated allocation of memory avoids.
- Workloads sensitive to CPU steal time. Databases are often single-threaded per query, so a virtual CPU that's ready to run but waiting on the physical host directly shows up as query latency. See the steal-time troubleshooting section in Choosing a CPU for CI/CD, virtualisation and Kubernetes nodes for how to check this and what it means once you find it.
Bare Metal Compute and Dedicated Servers both remove the virtualisation layer entirely: no other tenant's workload competes with yours for CPU or storage I/O. For the practical difference between the two products, see Bare Metal Compute vs. Dedicated Servers.
General self-managed database best practice
| Practice | Why it matters |
|---|---|
| Separate the database from the application tier as traffic grows | Running both on one server means they compete for the same CPU, RAM and I/O; separating them lets you scale and tune each independently |
| Put the data directory on the storage tier the workload justifies | NVMe for latency-sensitive production data, SATA SSD or HDD for cold or archival data; see Choosing storage media |
| Plan backup and replication strategy before you need it | A recovery plan designed after data loss has already happened is a plan that arrived too late; see Backups and snapshots for the underlying concepts |