When Your Database Outgrows a VPS

Databases are usually the first part of a stack to outgrow a VPS. Web servers can be multiplied behind a load balancer, but a PostgreSQL or MySQL primary wants one machine with enough memory to hold its hot data, storage fast enough to keep up with writes, and cores that nobody else is using. When those three run short, a dedicated database server is often the cheapest fix, and it can buy you years before you need to think about sharding.

This guide covers how to tell your database has outgrown its VPS, how to size a dedicated replacement, and how to move without losing data or sleep.

Signs your database has outgrown its VPS

• The working set no longer fits in memory. When the data your queries touch every day is bigger than the RAM available for caching, reads go to disk and response times climb.
• Disk wait shows up during busy hours. Tools like iostat or vmstat show the CPU waiting on storage while queries pile up.
• You are on the largest VPS already. Our biggest regular plan is 8 vCPU and 32 GB. Beyond that, the next step is a whole machine.
• Maintenance windows keep growing. Vacuum, index rebuilds and backups that took minutes now take hours.

If you are not there yet, our guides on sizing PostgreSQL on a VPS and sizing Redis and Valkey will help you get more out of the plan you have.

Sizing a dedicated database server

Memory first

Measure the working set: the tables and indexes your queries touch on a normal day. Then pick a server with enough memory to hold it with room to grow, plus a few gigabytes for connections and the operating system. Do not size for total database size. A 600 GB database with a 60 GB working set runs comfortably in 128 GB of memory.

Storage second

Databases care about latency more than raw capacity. NVMe drives answer small random reads and writes far faster than SATA SSDs, which is exactly the pattern of a busy transactional database. Always use at least two drives in a mirror so a single drive failure does not stop the database.

Cores third

Most single database servers are limited by memory and storage long before CPU. Faster cores help with complex queries and with many short transactions, more cores help with many parallel connections and analytics.

Which of our servers fits

The Xeon builds include one 240 GB SSD, so add a second drive at checkout for a mirror, and more if the data needs it. They take up to six SSDs. All prices include a 1 Gbps unmetered port, and our Xeon versus EPYC guide explains the trade offs between the two families in more depth.

Setting it up properly

1. Mirror the data disks. Use software RAID 1 or a ZFS mirror. Our RAID explainer covers the options.
2. Tune memory settings for the new size. The defaults assume a small machine. For PostgreSQL, raise shared_buffers and effective_cache_size. For MySQL, raise innodb_buffer_pool_size.
3. Keep the database off the public internet. Allow connections only from your application servers, through the firewall or a private tunnel such as WireGuard. Our hardening checklist covers the basics.
4. Back up to another city. Stream WAL or binary logs and nightly base backups to a separate machine. A small VPS works well as an off site backup target.
5. Add a replica when you can. A second server with a streaming replica gives you a warm standby and a place to run reports without touching the primary.

Moving from the VPS with minimal downtime

1. Order the dedicated server in the same country as your application, or the nearest one, to keep query latency low.
2. Set it up as a replica of the current VPS database, using native streaming replication for PostgreSQL or source and replica replication for MySQL.
3. Let it catch up and watch the replication lag fall to zero.
4. In a short maintenance window, stop writes, confirm the replica is current, promote it, and point the application at the new address.
5. Keep the old VPS for a few days as a fallback, then cancel it.

Done this way, the write outage is usually measured in minutes. Our general migration guide covers the DNS side of the switch.

A common pattern: dedicated core, VPS around it

Many teams end up with one dedicated server for the database and a few small VPS for everything else: two web nodes, a cache, a backup target in another city, and a monitoring probe. The database gets a whole machine, and the parts that scale sideways stay cheap and easy to replace. Dedicated servers are available in 11 countries and VPS in seven, so you can keep both close together.

How Noded Can Help

Choose a server on the dedicated page, add the drives you need for a mirror, and pick the country where your application runs. There is no setup fee and the port is unmetered. If you send us your database engine, total size, rough working set and peak queries per second in a ticket, we will suggest a configuration and tell you plainly if a bigger VPS would still do the job.

FAQ

How much RAM does a dedicated database server need?

Enough to hold the working set, the data your queries touch regularly, plus room for connections and growth. That is usually far less than the total database size.

NVMe or SSD for a database?

NVMe for busy, write heavy databases, because it handles small random reads and writes much faster. SATA SSD is fine for read heavy databases whose working set fits in memory.

Can I get a dedicated database server quickly?

Intel Xeon servers are delivered in about 45 minutes. AMD EPYC servers, which include NVMe, have a delivery estimate of 14 days.

Do you manage the database for me?

No. Dedicated servers are unmanaged with full root, so you install and run the database yourself. We look after the hardware and the network.