---
title: "How to choose a VPS for a database: RAM, CPU and NVMe | StreetHosting"
description: "Size the VPS for your database by data size, connections and write load: RAM, CPU, NVMe, IOPS, network and real plans compared side by side."
url: "https://streethosting.com.br/en/guides/vps/choose-vps-for-database"
type: "page"
language: "en-US"
---

VPS · 9 min · Intermediate

Published on Sep 28, 2026 · Updated on Sep 28, 2026

# VPS for databases: how to size it without overpaying

A slow database is rarely fixed with more vCPUs: almost always it is short on RAM for the hot data or stuck on disk latency. Learn how to measure what your database actually consumes and pick the plan by the right number.

By [Equipe StreetHosting](https://streethosting.com.br/en/autores#equipe-streethosting) · StreetHosting infrastructure and support team

[Databases](https://streethosting.com.br/en/guides/topics/databases) [Hardware and datacenter](https://streethosting.com.br/en/guides/topics/hardware) [Performance and optimization](https://streethosting.com.br/en/guides/topics/performance) [Costs, plans and billing](https://streethosting.com.br/en/guides/topics/costs)

Summarize with:

[](https://chat.openai.com/?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fchoose-vps-for-database.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "ChatGPT") [](https://claude.ai/new?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fchoose-vps-for-database.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Claude") [](https://www.google.com/search?udm=50&aep=11&q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fchoose-vps-for-database.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Google AI Mode") [](https://x.com/i/grok?text=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fchoose-vps-for-database.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Grok") [](https://www.perplexity.ai/search/new?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fchoose-vps-for-database.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Perplexity")

Share:

[](https://x.com/intent/tweet?text=How%20to%20choose%20a%20VPS%20for%20a%20database%3A%20RAM%2C%20CPU%20and%20NVMe&url=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fchoose-vps-for-database "Share on X") [](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fchoose-vps-for-database "Share on Facebook") [](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fchoose-vps-for-database "Share on LinkedIn") [](https://wa.me/?text=How%20to%20choose%20a%20VPS%20for%20a%20database%3A%20RAM%2C%20CPU%20and%20NVMe%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fchoose-vps-for-database "Share on WhatsApp")

For agents: Copy as Markdown [.md](https://streethosting.com.br/en/guides/vps/choose-vps-for-database.md)

In this guide 8 sections

* [What a database consumes](https://streethosting.com.br/en/guides/vps/choose-vps-for-database#o-que-importa)
* [RAM: the hot data set](https://streethosting.com.br/en/guides/vps/choose-vps-for-database#ram)
* [NVMe, IOPS and write latency](https://streethosting.com.br/en/guides/vps/choose-vps-for-database#disco)
* [CPU: Xeon or Ryzen for databases](https://streethosting.com.br/en/guides/vps/choose-vps-for-database#cpu)
* [Network, location and stability](https://streethosting.com.br/en/guides/vps/choose-vps-for-database#rede-estabilidade)
* [Sizing table](https://streethosting.com.br/en/guides/vps/choose-vps-for-database#tabela)
* [Database on the same VPS or separate](https://streethosting.com.br/en/guides/vps/choose-vps-for-database#mesma-vps)
* [Which plan to get](https://streethosting.com.br/en/guides/vps/choose-vps-for-database#onde-rodar)

Quick answer

To choose a **VPS for a database**, start with RAM: indexes and frequently queried data need to fit in memory. Then look at the disk's write latency, which NVMe handles well, and only then at the CPU. Xeon delivers more RAM and vCPUs for the money when you have many connections; the Ryzen 9 9950X speeds up heavy queries. A database up to 10 GB runs well with 8 GB of RAM, starting at R$ 77.00 per month on the Xeon line.

## What a database consumes[](https://streethosting.com.br/en/guides/vps/choose-vps-for-database#o-que-importa)

A typical web application spends most of its time waiting on the database, and the database spends most of its time waiting on the disk when memory is not enough. That is why the order of priority for transactional databases, such as PostgreSQL, MySQL, MariaDB and MongoDB, usually looks like this:

* **RAM:** determines how much of the database is served without touching the disk. Lack of memory is the most common cause of slowness.
* **Disk latency:** every committed transaction waits for the write to the log. A slow disk limits how many commits per second the database can handle.
* **CPU:** matters for complex queries, sorting, aggregations and many connections at the same time.
* **Network:** almost never a bandwidth bottleneck, but the distance between application and database gets multiplied by the number of queries in each request.

Redis is the exception: the entire data set lives in memory, so its math is almost all RAM. Generic project sizing works as a starting point; here the focus is on what changes when the database is the main workload.

## RAM: the hot data set[](https://streethosting.com.br/en/guides/vps/choose-vps-for-database#ram)

No database needs the whole file in memory. It needs the hot set: the indexes and the rows that are read all the time. A store with 20 GB of order history may have only 2 GB of data queried every day. If those 2 GB and the indexes fit in RAM, the database responds fast; if they do not, every query turns into a disk read. Each engine uses memory in its own way:

| Database          | Where the cache lives                                | Starting point on a VPS dedicated to the database              |
| ----------------- | ---------------------------------------------------- | -------------------------------------------------------------- |
| PostgreSQL        | shared\_buffers plus the operating system file cache | shared\_buffers at 25% of RAM, the rest goes to the system     |
| MySQL and MariaDB | innodb\_buffer\_pool\_size                           | 50% to 70% of RAM, leaving headroom for connections            |
| MongoDB           | WiredTiger cache plus the system cache               | By default, half of what is left of RAM after subtracting 1 GB |
| Redis             | The entire data set                                  | maxmemory below RAM, with headroom for the persistence process |

To estimate, measure the current size of the data and the indexes. The commands below show it in each database:

`-- PostgreSQL SELECT pg_size_pretty(pg_database_size('meu_banco')); -- MySQL and MariaDB (in MB, per database) SELECT table_schema, ROUND(SUM(data_length + index_length) / 1024 / 1024) AS mb FROM information_schema.tables GROUP BY table_schema; // MongoDB, in mongosh (in MB) db.stats(1024 * 1024)`

Add the memory for connections on top of the cache. In PostgreSQL, each connection is a process that consumes a few MB while idle and more memory when it sorts or groups results. A hundred connections left open by a poorly configured application take a real slice of RAM, which is why a pooler like PgBouncer comes into play, as shown in the guide on [PostgreSQL on a VPS](https://streethosting.com.br/en/guides/vps/install-postgresql-ubuntu-vps).

Databases and swap do not mix. When the system starts pushing database pages out to disk, latency explodes with no visible error. A small swap works as a safety net against the OOM killer, but if it is in use all the time, you are short on RAM.

## NVMe, IOPS and write latency[](https://streethosting.com.br/en/guides/vps/choose-vps-for-database#disco)

Two numbers define the disk for a database. The first is IOPS on random reads and writes of small blocks, which is how a database accesses storage when the data is not in memory. The second, more important and less often remembered, is sync latency: a commit is only confirmed after the transaction log has been written durably. That time is what limits how many transactions per second the database confirms.

Every StreetHosting VPS uses NVMe, which has far lower latency than SATA SSD or HDD. Instead of trusting a spec sheet number, measure on your VPS with `fio`:

`sudo apt install -y fio # random read and write in 4 KB blocks, 70% read fio --name=aleatorio --filename=/var/tmp/fio.teste --size=2G --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --ioengine=libaio --direct=1 --runtime=60 --time_based --group_reporting # write latency with a sync on every block, similar to a commit fio --name=commit --filename=/var/tmp/fio.sync --size=256M --rw=write --bs=8k --ioengine=sync --fdatasync=1 --runtime=30 --time_based rm /var/tmp/fio.teste /var/tmp/fio.sync`

In the first test, look at the read and write IOPS. In the second, look at the sync latency percentiles: the lower and more stable they are, the more commits per second. PostgreSQL users also have `pg_test_fsync`, which compares the available sync methods. Run the tests at different times of day: stability over the day says as much as the peak number.

For disk space, add up data, indexes, the transaction log, local backup copies and a year of growth, and keep at least 30% free. Operations like `VACUUM FULL` in PostgreSQL or table alterations in MySQL rewrite the whole table and need temporary space of the same size.

## CPU: Xeon or Ryzen for databases[](https://streethosting.com.br/en/guides/vps/choose-vps-for-database#cpu)

In most databases, a query runs mainly on a single core. PostgreSQL can parallelize large scans, but the common case for a web application is many short queries from many connections at the same time. That creates two different situations:

* **Many connections, simple queries:** what matters is having cores to serve all of them in parallel. The Xeon E5-2680 v4 line delivers more vCPUs for the money and fits this profile.
* **Few heavy queries:** reports, aggregations, JSON searches and large joins depend on the speed of each core. The Ryzen 9 9950X, with up to 5.7 GHz and DDR5, cuts the time of each one.

The difference between the two profiles is detailed in the comparison [Ryzen VPS or Xeon VPS](https://streethosting.com.br/en/guides/vps/ryzen-vs-xeon-vps). Before switching CPUs, check that the problem is not a query without an index: the right index usually pays off more than any upgrade.

## Network, location and stability[](https://streethosting.com.br/en/guides/vps/choose-vps-for-database#rede-estabilidade)

A request that runs 30 queries against the database pays the round-trip latency 30 times. With database and application on the same VPS, that latency is microseconds. With the database in another country, each query costs tens of milliseconds, and the page that loaded in 50 ms starts taking more than a second. That is why the database should sit close to the application, and the application close to the users: for a Brazilian audience, both in São Paulo.

Stability on a VPS means getting the CPU you pay for when the database needs it. The indicator is steal time, which shows how long your VM waited for the physical processor. Track it with `vmstat 1 10`, in the _st_ (steal) and _wa_ (I/O wait) columns. What is normal and what signals a problem is covered in [what CPU steal is](https://streethosting.com.br/en/guides/vps/what-is-cpu-steal-vps).

* Database port closed to the internet, reachable only by the application or over VPN
* Backup scheduled and copied off the VPS
* Restore tested at least once a quarter
* Alert for disk above 80% and for swap in continuous use
* Monitoring of open connections and slow queries

Backups deserve a spotlight: the VPS does not include a backup service or automatic snapshots, so copying the data is your responsibility. The guide on [automatic backups with restic and cron](https://streethosting.com.br/en/guides/vps/vps-backup-restic-cron) shows how to send the dumps to an external destination.

## Sizing table[](https://streethosting.com.br/en/guides/vps/choose-vps-for-database#tabela)

The table starts from the database size on disk and the volume of connections and suggests a plan from each line. Treat it as a starting point: measure real usage over the first weeks and adjust.

| Scenario                                           | Data and connections                | Xeon VPS                                                | Ryzen 9 9950X VPS                                  |
| -------------------------------------------------- | ----------------------------------- | ------------------------------------------------------- | -------------------------------------------------- |
| MVP, bot or small site with the database alongside | Up to 2 GB, a few dozen connections | 3 vCPU, 4 GB, 40 GB: R$ 43.00                           | 2 vCPU, 4 GB, 40 GB: R$ 66.00                      |
| Online store or early-stage SaaS                   | Up to 10 GB, up to 100 connections  | 6 vCPU, 8 GB, 80 GB: R$ 77.00                           | 4 vCPU, 8 GB, 80 GB: R$ 118.00                     |
| Growing SaaS database                              | 10 to 40 GB                         | 9 vCPU, 16 GB, 160 GB: R$ 145.00                        | 6 vCPU, 16 GB, 160 GB: R$ 222.00                   |
| Many simultaneous customers and reports            | 40 to 120 GB                        | 15 vCPU, 32 GB, 320 GB: R$ 281.00                       | 10 vCPU, 32 GB, 320 GB: R$ 430.00                  |
| Large database with heavy indexes                  | 120 to 400 GB                       | 24 vCPU, 64 GB, 640 GB: R$ 553.00                       | 14 vCPU, 64 GB, 640 GB: R$ 846.00                  |
| Above 640 GB or more than 64 GB of RAM             | Data and cache beyond the VPS limit | AMD Budget LG dedicated, 128 GB, 2 TB NVMe: R$ 1,699.00 | AMD Extreme SM dedicated, 128 GB DDR5: R$ 2,229.00 |

The ranges leave disk room for indexes, the transaction log and a local backup copy. If the hot set is small relative to the total, as with history that is almost never read, one plan down may be enough. The Budget line with the Ryzen 9 5900XT appears on the same Ryzen page but is out of stock at the moment.

## Database on the same VPS or separate[](https://streethosting.com.br/en/guides/vps/choose-vps-for-database#mesma-vps)

Starting with application and database on the same VPS is the right call for most projects: less latency, lower cost and fewer moving parts to manage. Splitting them starts to make sense in concrete situations:

* **Memory contention:** application spikes push the database cache out and queries slow down right at peak traffic.
* **Several applications on the same database:** a central database server avoids duplicated data and simplifies backups.
* **Application on more than one server:** to spread the application behind a load balancer, the database has to live outside the instances.
* **Isolation:** a security flaw in the application does not give direct access to the system where the data lives.

When you split them, connect the two VPS over a [WireGuard](https://streethosting.com.br/en/guides/vps/wireguard-vpn-vps) tunnel and make the database listen only on the VPN address. The database port stays closed to the internet and traffic between the servers travels encrypted.

## Which plan to get[](https://streethosting.com.br/en/guides/vps/choose-vps-for-database#onde-rodar)

For most databases, the [Xeon VPS](https://streethosting.com.br/en/vps/xeon) is the starting point: Xeon E5-2680 v4 with DDR4 and NVMe, from R$ 26.00 (2 vCPU, 2 GB, 20 GB) to R$ 553.00 (24 vCPU, 64 GB, 640 GB). It gives you more RAM and vCPUs for the money, exactly the two resources a database with many connections consumes. When the bottleneck is heavy query time, the [Ryzen 9 9950X VPS](https://streethosting.com.br/en/vps/ryzen), with DDR5 and up to 5.7 GHz, runs from R$ 40.00 to R$ 846.00. Both lines are hosted in São Paulo, with Anti-DDoS, root access and KVM virtualization.

Upgrades are done from the control panel, charge only the prorated difference for the billing cycle and require a VM restart, so schedule them for a low-traffic window. After the upgrade, adjust the database's memory parameters, because most of them do not follow the new RAM on their own. Disk grows with the plan, but shrinking is not always possible: buy space for the next year, not the next five. Above 640 GB or 64 GB of RAM, the [dedicated servers](https://streethosting.com.br/en/dedicated) in São Paulo bring 2 TB NVMe and 64 to 192 GB of memory on the AMD line.

In this guide

* [What a database consumes](https://streethosting.com.br/en/guides/vps/choose-vps-for-database#o-que-importa)
* [RAM: the hot data set](https://streethosting.com.br/en/guides/vps/choose-vps-for-database#ram)
* [NVMe, IOPS and write latency](https://streethosting.com.br/en/guides/vps/choose-vps-for-database#disco)
* [CPU: Xeon or Ryzen for databases](https://streethosting.com.br/en/guides/vps/choose-vps-for-database#cpu)
* [Network, location and stability](https://streethosting.com.br/en/guides/vps/choose-vps-for-database#rede-estabilidade)
* [Sizing table](https://streethosting.com.br/en/guides/vps/choose-vps-for-database#tabela)
* [Database on the same VPS or separate](https://streethosting.com.br/en/guides/vps/choose-vps-for-database#mesma-vps)
* [Which plan to get](https://streethosting.com.br/en/guides/vps/choose-vps-for-database#onde-rodar)

## Frequently asked questions

How much RAM does a VPS for a database need?

Ideally the indexes and the frequently queried part of the data fit in memory, plus the memory for connections and the operating system. For databases up to a few GB, 4 to 8 GB does the job; databases in the tens of GB usually call for 16 to 32 GB.

Is Xeon or Ryzen better for databases?

Xeon delivers more vCPUs and more RAM for the money, which favors many simultaneous connections and databases that need memory. The Ryzen 9 9950X has a much higher clock and cuts the time of individual heavy queries, such as reports and aggregations.

Does NVMe make a difference for databases?

It does, mainly on writes. Every committed transaction waits for the disk to make the data durable, and NVMe responds much faster than SATA SSD or HDD. When the data does not fit in RAM, reads also start to depend on the disk.

Is it better to keep the database on the same VPS as the application?

For small and medium projects, yes: the latency between application and database stays minimal and the cost goes down. Separate them when the two compete for RAM, when several applications use the same database, or when the application needs to scale across more than one server.

Does the StreetHosting VPS back up my database?

No. The VPS does not include a backup service or automatic snapshots, so backups are the responsibility of whoever administers the server. Schedule pg\_dump, mysqldump or mongodump and send the copies off the VPS.

Next step

See Xeon VPS

Xeon VPS for steady workloads, automation and long-running projects.

[See Xeon VPS](https://streethosting.com.br/en/vps/xeon)

[See VPS plans Root VPS in Brazil with NVMe and Anti-DDoS.](https://streethosting.com.br/en/vps) [See Ryzen VPS Ryzen 9 9950X VPS in São Paulo with root access, NVMe and gamer Anti-DDoS.](https://streethosting.com.br/en/vps/ryzen) [See dedicated servers Exclusive hardware in São Paulo with NVMe and Anti-DDoS.](https://streethosting.com.br/en/dedicated)

## Related guides

[VPS Intermediate How to install PostgreSQL on an Ubuntu VPS securely PostgreSQL is the most complete open source relational database and the default for many modern applications. Learn how to install it on an Ubuntu VPS, create a user and database for your application, understand authentication, allow remote access without exposing the port, schedule backups and tune memory. 10 min Read guide](https://streethosting.com.br/en/guides/vps/install-postgresql-ubuntu-vps) [VPS Intermediate How to install MongoDB on an Ubuntu VPS with authentication Fresh out of the box, MongoDB accepts local connections with no password, and a misconfigured bindIp leaves it wide open to the internet. Here is how to install 8.0 from the official repository, enable authentication and give each application a user that can only reach its own database. 10 min Read guide](https://streethosting.com.br/en/guides/vps/install-mongodb-ubuntu-vps) [VPS Intermediate How to install and configure Redis on an Ubuntu VPS Redis is an in-memory database used as a cache, a queue and a session store. Learn how to install it on Ubuntu, protect it with a password or ACL, cap its RAM with the right eviction policy, choose between RDB and AOF, and connect your application. 10 min Read guide](https://streethosting.com.br/en/guides/vps/install-redis-ubuntu-vps)

[← Back to the Guide Center](https://streethosting.com.br/en/guides)
