keepcalculator

06 Numbers and Powers

MySQL RAM Requirements: Why 1 GB Minimum on a VPS

Card No. 06·51149 · Updated · Standard formula, shown below

MySQL needs at least 1 GB of RAM on a VPS because its default configuration and typical workloads assume a memory footprint of several hundred megabytes just for buffers, caches, and connection handling—below that, the database either refuses to start or swaps so heavily that performance collapses. This article explains the memory components that drive that requirement, how to size RAM for your actual use case, and what happens when you under-provision.

What Actually Consumes RAM in MySQL

MySQL is not a single process with one fixed memory cost. It allocates memory across several subsystems, and the sum of those allocations is what you see in top or htop. The main consumers are:

  • InnoDB buffer pool – caches table data and indexes in memory. This is the largest consumer, often 50–75% of total MySQL memory. The default value in MySQL 8.0 is 128 MB, but for any real database you will set it higher.
  • Connection threads – each active connection gets its own thread with a stack and a set of per-session buffers. A single connection can use 1–10 MB depending on configuration and query complexity.
  • Global caches – the query cache (deprecated in MySQL 8.0), key buffer for MyISAM, table open cache, and various internal structures.
  • Temporary tables and sort buffers – created during queries with ORDER BY, GROUP BY, or complex joins. These are allocated per connection and can be large.
  • Replication and binary log buffers – used for replication threads and binary log caching.

On a fresh install with defaults, MySQL might idle at 300–500 MB of RSS. With a modest workload (a few dozen connections and a 256 MB buffer pool), you are already at 600–800 MB. That is why 1 GB is the practical floor for a VPS that runs anything beyond a toy database.

The Default Configuration Assumes 1 GB

MySQL’s installer and package scripts detect system memory and adjust key variables. On a machine with less than 1 GB, the configuration often falls back to very conservative values—or the service fails to start because the buffer pool size plus overhead exceeds available RAM.

In MySQL 8.0, the default innodb_buffer_pool_size is 128 MB, but the recommended sizing for a dedicated database server is 70–80% of total RAM. On a 1 GB VPS, that means a buffer pool of 700–800 MB, leaving room for connections and OS cache. If you try to run MySQL on a 512 MB VPS with a 700 MB buffer pool, the kernel will swap constantly, and queries that would take milliseconds will take seconds.

Additionally, MySQL 8.0 introduced the innodb_dedicated_server option, which automatically sizes the buffer pool and log files based on detected RAM. If you enable it on a 1 GB VPS, it sets the buffer pool to about 50% of RAM (512 MB) and adjusts other settings. This is a good starting point for a dedicated MySQL server.

How to Choose the Right RAM Size

There is no single “correct” amount of RAM for MySQL because it depends on your data size, workload, and concurrent users. Use these guidelines:

  • 1 GB – minimum for a small production database (e.g., a WordPress site with a few thousand visitors/day). Expect a buffer pool of 256–512 MB and limited headroom.
  • 2 GB – comfortable for a small to medium web application with dozens of concurrent connections and a database under 10 GB.
  • 4 GB – good for larger databases (10–50 GB) with moderate traffic and complex queries.
  • 8 GB+ – needed when the working set (frequently accessed data) exceeds 4 GB, or for heavy analytics workloads.

The key rule: your working set should fit in the buffer pool. If your database is 20 GB but you only access 2 GB of it regularly, a 4 GB buffer pool will be fine. If you access all 20 GB frequently, you need at least 16–20 GB of RAM.

What Happens When You Under-Provision RAM

Running MySQL on a VPS with too little RAM leads to a cascade of problems:

  • Swapping – the OS moves memory pages to disk. Since disk I/O is thousands of times slower than RAM, queries become painfully slow.
  • OOM killer – the Linux kernel may kill MySQL to free memory. This results in unexpected downtime and potential data corruption (though InnoDB recovers on restart).
  • Connection failures – MySQL rejects new connections when it cannot allocate memory for threads.
  • Slow backups – tools like mysqldump add memory pressure and can cause the server to swap even more.

A common mistake is to set innodb_buffer_pool_size to 800 MB on a 1 GB VPS, leaving almost nothing for the OS and connections. The server may start, but it will be in a constant state of thrashing. Always leave at least 20–30% of RAM for the OS, file cache, and connection overhead.

Alternatives to Reducing Memory Usage

If you are stuck with a small VPS, you can tune MySQL to use less memory, but there are trade-offs:

  • Reduce buffer pool size – set it to 128–256 MB. This increases disk I/O but keeps the server alive.
  • Limit connections – set max_connections to 10–20 instead of the default 151. Each connection costs memory.
  • Use MariaDB – MariaDB is a MySQL fork that tends to use slightly less memory for the same workload, though the difference is not huge.
  • Switch to SQLite – for very small applications (under 1 GB of data, low concurrency), SQLite runs in-process and uses far less memory. This is not a drop-in replacement for MySQL, but it can be a pragmatic choice for a low-traffic side project.

However, these measures only stretch a small amount of RAM so far. For any serious growth, upgrading to 2 GB is cheaper than the engineering time spent fighting memory limits.

Cost and Performance Trade-offs

On a VPS, RAM is the most expensive resource per gigabyte. A 1 GB VPS is often $5–10/month, while a 2 GB VPS is $10–20/month. The jump from 1 GB to 2 GB typically doubles the cost but gives you a much more usable MySQL server.

The performance difference is dramatic: with 1 GB, your buffer pool is limited to ~512 MB, so any data beyond that is read from disk. With 2 GB, you can have a 1.5 GB buffer pool, which may cover your entire working set. In practice, this can cut query latency from 100 ms to 1 ms for cached data.

Before upgrading, measure your current memory usage with free -m and SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read_requests' versus ..._reads. If the cache hit ratio is below 95%, more RAM will help.

Frequently Asked Questions

Can MySQL run on 512 MB of RAM?

Technically yes, but only with a very small buffer pool (64–128 MB) and a minimal workload. You will likely experience swapping and poor performance. It is not recommended for anything beyond a development environment.

Does MySQL use more RAM than PostgreSQL?

Both databases have similar memory profiles. PostgreSQL uses shared buffers plus per-connection work_mem, while MySQL uses InnoDB buffer pool plus per-connection sort/join buffers. In practice, both need at least 1 GB for a small production instance.

How do I check how much RAM MySQL is using?

On Linux, run ps aux | grep mysqld and look at the RSS column. For a more detailed breakdown, use SHOW GLOBAL STATUS for buffer pool and thread statistics, or query performance_schema.memory_summary_global_by_event_name.

Will adding swap space help?

Swap can prevent the OOM killer, but it does not fix performance. If MySQL swaps, queries will be slow. It is better to reduce memory usage or upgrade RAM than to rely on swap.

Is 1 GB enough for a WordPress site?

For a small WordPress site with low traffic (a few hundred visitors/day), 1 GB is sufficient if you keep the buffer pool around 256 MB and use a caching plugin. For higher traffic, 2 GB is safer.

Related

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.

More cards in this drawer

The whole Numbers and Powers drawer →