Database Servers on a VPS: Sizing RAM, Disk and Cache

A database is the one workload where guessing the plan size is expensive. Web servers degrade gracefully when they run out of headroom. A database that no longer fits its working set in memory does not slow down by ten percent, it falls off a cliff, because every query that used to be answered from RAM now waits for a disk.

This is how to size a PostgreSQL or MySQL server on a virtual machine, what our plans actually give you, and the point at which the honest answer is that you have outgrown a VPS.

Start with the working set, not the database size

The number that matters is not how big the database is. It is how much of it gets touched regularly. A 200 GB database where queries only ever read the last month of orders may have a working set of 6 GB, and it will be happy on a small machine. A 20 GB database where reports scan everything has a working set of 20 GB and will not be.

A usable rule: give the machine enough RAM for the working set, the database cache configured to roughly two thirds of that, plus about 1 GB for the operating system and whatever else runs on the box. If you do not know your working set yet, watch cache hit rates for a week. In PostgreSQL the ratio of blocks found in cache to blocks read from disk tells you plainly. In MySQL with InnoDB, the buffer pool read requests against actual disk reads say the same thing.

What our plans give a database

Plan	RAM	vCPU	SSD	Realistic database role
Ion	2 GB	1	20 GB	A development database, or a small application database with a working set under 1 GB
Pulse	4 GB	2	40 GB	A single small production application, cache configured around 2 GB
Core	8 GB	2	60 GB	The common sweet spot for one busy application, cache around 5 GB
Forge	16 GB	4	80 GB	Several applications, or one with reporting queries alongside it
Apex	24 GB	6	100 GB	A busy primary with concurrent analytical work
Titan	32 GB	8	120 GB	The largest we offer as a virtual machine, working set up to roughly 26 GB

Disk can be extended by 50 GB units at €4 per unit per month, up to three units, so a Titan can carry 270 GB in total. Every plan includes one IPv4 address and unmetered traffic, which matters for replication because you are not billed for the bytes a replica pulls. Full per city prices are in our price by location breakdown.

Disk is the part people get wrong

Three things about storage are worth being direct about.

• Plan for three copies of the data. The live database, the space a dump needs, and the space a restore or a table rewrite needs. A 60 GB disk does not hold a 50 GB database comfortably. Aim to stay under half the disk in steady state.
• Our pools are mirrored SSD, not guaranteed IOPS. Storage is fast and it is redundant against a disk failure, and it is shared capacity rather than a pinned performance figure. For a transactional workload in the sizes above this is a non issue. If your requirement is written as a specific sustained IOPS number in a contract, that requirement wants bare metal with its own disks, and we would rather tell you now than after the migration.
• Write amplification is real. Heavy write workloads on a small plan hit disk far harder than the query count suggests, because of journals, write ahead logs and checkpoints. If your load is write dominated, buy one size up from what the read numbers imply. Our comparison of SSD against NVMe covers why this shows up as latency rather than throughput.

Where to put the database

Next to the application that queries it. This sounds obvious and gets ignored constantly. An application in Frankfurt querying a database in Bucharest pays the round trip on every single query, and a page that issues forty queries pays it forty times. A 10 ms separation turns into 400 ms of page time, which no amount of RAM fixes.

All five of our VPS cities host both halves, so keep the pair together and choose the city for the users, not for the database.

• Frankfurt or Amsterdam for Western European traffic.
• Vienna for Austria and the neighbouring Central European markets, 4 ms from the hub.
• Warsaw for Poland and the Baltics.
• Bucharest for the Balkans, and for the lowest price on any plan in the range.

The one thing worth putting in a different city is the replica, which is the subject of pairing two locations.

Replicas, backups and the difference between them

A replica protects against a machine or a site failing. It does not protect against a bad migration, a dropped table or ransomware, because all of those replicate perfectly. You need both, and they are not substitutes.

• Streaming replication to a second machine, ideally in a second city, gives you a warm standby. Unmetered traffic means the replication stream does not cost extra.
• Your own backups, tested. Take a logical dump on a schedule, push it somewhere that is not the same server, and restore it somewhere else once in a while. An untested backup is a hope. Our walkthrough on automating backups is the practical version, and the useful trick is to restore the dump onto a machine you rent by the hour, verify it, and delete it. A Forge for two hours is under ten cents.

Configuration that earns its keep in ten minutes

1. Set the cache size deliberately. PostgreSQL ships with a small shared buffer figure and MySQL with a small buffer pool. Neither default reflects the machine you just bought.
2. Tell the planner about your disk. On PostgreSQL, random page cost tuned for solid state storage changes plans for the better.
3. Cap connections and put a pooler in front. Hundreds of idle connections cost memory that your cache wanted. A pooler is cheaper than the next plan up.
4. Turn on slow query logging and read it. One missing index is worth more than any of the above.
5. Never expose the database port to the internet. Bind to localhost for a single box, and for a split pair allow only the application address through the firewall. The rules in setting up a firewall cover the second case.

When a VPS is no longer the right shape

Four signals, any one of which means the conversation should move to bare metal.

• The working set is above roughly 26 GB. A Titan is our largest virtual machine at 32 GB of RAM. Our dedicated range starts at 128 GB and goes to 1 TB.
• The data will pass 270 GB. That is a Titan with all three storage units attached. A dedicated server takes far more disk, and takes it as its own drives.
• You need a specific sustained IOPS or throughput figure in writing. Shared storage is the wrong answer to a contractual number.
• The database is the whole business. At that point the economics of a machine nobody else shares stop being a luxury. The comparison in VPS against dedicated servers walks through the trade properly.

Starting point

For a single busy application, a Core in the same city as the application server is the plan that fits most often, and moving up to a Forge later is a resize rather than a rebuild. Plans are on the VPS page, the database workload page has the summary, and if you can tell us your working set and query rate we will tell you which plan we would actually pick.