How to Choose the Right VPS Specs for a Database Server

Databases stress a server differently from a website. Memory and disk speed decide how fast queries run far more often than CPU does. This guide explains how to size a VPS for MySQL, MariaDB, PostgreSQL, MongoDB or Redis, how to measure what your database actually uses, and when to move it onto its own server.

Memory: The Resource That Matters Most

A database is fastest when the data it reads often — its working set — fits in memory, in InnoDB’s buffer pool, PostgreSQL’s shared buffers and the operating system’s page cache. When it does not fit, queries wait on the disk. As a starting point:

The working set is often much smaller than the whole database — an old orders table nobody reads does not need to be in memory. If the application runs on the same server, add its own memory needs on top.

Redis is the exception to all of this: it keeps everything in memory, so the server needs more RAM than the full data set plus room for persistence snapshots.

Storage: Fast Disks for Small, Random Reads

Databases issue a stream of small, random reads and writes, often many at once. That is exactly where NVMe storage pulls ahead of older disk types, because it can keep many operations in flight. For a database server, choose NVMe — on VPS For Life, NVMe is used on the NVMe VPS range and others; the storage per range is on the hardware specifications page. The difference is explained in NVMe vs SSD.

Leave free space: databases need room for temporary files, indexes being rebuilt, write-ahead logs and backups taken locally before they are copied off. Running out of disk can stop the database and, in the worst case, corrupt data.

CPU: Usually the Last Bottleneck

Most application databases are limited by memory and I/O. Two to four cores serve many small and medium applications. CPU becomes the limit with heavy reporting queries, large aggregations, full-text search, or many concurrent connections — and often a missing index is the real cause.

Shared or Dedicated Resources?

For databases that need consistent performance under sustained load, dedicated resources remove a variable. Our VDS range has dedicated RAM, which suits busy production databases.

Measure Before You Size

Database size — MySQL / MariaDB:

SELECT table_schema AS db,
  ROUND(SUM(data_length + index_length) / 1024 / 1024) AS size_mb
FROM information_schema.tables GROUP BY table_schema ORDER BY size_mb DESC;

PostgreSQL:

SELECT datname, pg_size_pretty(pg_database_size(datname)) FROM pg_database ORDER BY pg_database_size(datname) DESC;

Is memory big enough? — MySQL / MariaDB buffer pool reads that missed memory:

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';

If Innodb_buffer_pool_reads (from disk) is more than about 1% of Innodb_buffer_pool_read_requests, the working set does not fit. PostgreSQL cache hit ratio:

SELECT round(100.0 * sum(blks_hit) / nullif(sum(blks_hit) + sum(blks_read), 0), 2) AS cache_hit_pct FROM pg_stat_database;

Aim for 99% or more on a busy database.

Is the disk the bottleneck?

sudo apt install sysstat -y
iostat -x 5

Consistently high %util and await on the database disk, together with high wa in top, point to storage. See How to Diagnose High CPU Usage for telling CPU and I/O apart.

Configure It for the Server You Have

Default settings assume a tiny machine. Starting points:

• MySQL / MariaDB: innodb_buffer_pool_size at 50–70% of RAM on a database-only server, less if the application shares the server.
• PostgreSQL: shared_buffers about 25% of RAM, effective_cache_size about 50–75%.
• Redis: set maxmemory and an eviction policy, so it cannot take all the RAM.

More in How to Tune MySQL/MariaDB Performance.

Same Server as the App, or Its Own?

Start on one server. Move the database out when you see real contention — the web server and database fighting for memory, or disk wait rising under normal traffic — or when you need separate backup and maintenance schedules. Keep both servers in the same datacenter so queries do not cross the internet.

Signs It Is Time to Grow

• Queries that used to be fast now appear in the slow query log.
• The cache hit ratio is falling as data grows.
• Disk wait is high during normal traffic, not only at peaks.
• The server swaps.
• Connection timeouts at ordinary load.

Backups Are Part of Sizing

Dumps and snapshots need disk space and I/O while they run, and they must end up off the server — we do not hold backups of customer servers. Leave room for at least one local dump, and schedule backups away from peak traffic.

Continue Reading

• MySQL vs PostgreSQL vs MongoDB vs Redis
• How to Install PostgreSQL on AlmaLinux/Rocky Linux
• Database Security Checklist
• High Performance VPS

Browse more articles in Databases.