How Much RAM Does Your VPS Actually Need?

The honest answer: less than you think for most workloads, and more than the cheapest plan offers if you are running a database on the same server as your application. That middle ground is where most VPS buyers land, and getting it wrong in either direction costs money.

Overprovision and you pay for memory that sits idle every month. Underprovision and the Linux kernel's OOM killer starts terminating processes at the worst possible moment. That moment is almost always a traffic spike, exactly when your site needs to be running, not restarting.

This guide covers what actually consumes RAM on a typical VPS, how to estimate what your workload needs, and where the common sizing mistakes happen.

What Eats RAM on a Linux VPS

Before talking about plan sizes, it helps to know what is actually competing for memory on your server. Most VPS workloads involve some combination of these layers:

These are baseline ranges for modest, single-server setups. The numbers shift depending on configuration, traffic, and what your application actually does with the memory it allocates.

The operating system itself is the fixed cost. Everything above it stacks. A WordPress site running Nginx, PHP-FPM with four workers, and MariaDB on the same instance needs roughly 500 to 900 MB just to stay idle. Under load, those PHP-FPM workers consume more, MariaDB's buffer pool fills up, and you need headroom for the kernel's filesystem cache (which genuinely improves disk I/O performance rather than wasting memory).

Sizing by Workload

Not every project needs the same plan.

Static sites and simple proxies

A VPS serving static HTML, a reverse proxy for an external service, or a lightweight API gateway needs very little. Nginx barely registers in memory usage. The operating system is the dominant consumer.

Realistic minimum: 512 MB. Even 256 MB plans work if the provider offers them and you keep the service stack minimal. This is the one category where the cheapest plan genuinely makes sense.

WordPress and PHP-based CMS platforms

WordPress is one of the most common VPS workloads, and it is also where people most frequently undersize. The application itself is lightweight, but a real WordPress site runs PHP-FPM workers, a database, a web server, and usually a caching layer on top.

The critical variable is PHP-FPM worker count. Each worker handles one request at a time and holds its own memory allocation. Four workers at 50 MB each is 200 MB just for PHP, before the database or operating system take their share. The WordPress VPS setup guide walks through how to calculate worker count based on available memory.

Realistic minimum: 1 GB for a low-traffic site. 2 GB for a site with WooCommerce, a page builder, or moderate concurrent visitors. Below 1 GB, you will be constantly tuning worker counts and database buffers to avoid swapping.

Application servers (Node.js, Python, Ruby)

A single Node.js or Python application with a database sounds lightweight, and it can be. The reality depends on framework weight, concurrent connections, and whether the application holds data in memory (session stores, in-process caches, large response payloads).

A simple Express or Flask API with a small PostgreSQL database fits comfortably in 1 GB. A more complex application with background job processing, WebSocket connections, and larger data payloads pushes toward 2 GB.

Realistic minimum: 1 GB for a small application. 2 GB when adding background workers, job queues, or multiple services.

Java applications (Spring Boot, Quarkus)

The JVM is the outlier in memory consumption. A Spring Boot application's heap allocation depends on how it is configured, but production settings commonly reserve 256 to 512 MB of heap space. Add the JVM's metaspace, thread stacks, and non-heap memory on top of that, and the total JVM footprint can reach 400 to 600 MB before the application loads its first request.

Running that alongside a database on the same instance means the JVM and the database are competing for the same fixed pool of memory.

Realistic minimum: 2 GB with a co-located database. 4 GB if the application handles significant traffic or runs a larger heap configuration.

Self-hosted tool stacks

Running multiple self-hosted services (Gitea, Vaultwarden, Uptime Kuma, a reverse proxy, maybe Nextcloud) adds up differently than a single application. Each service has a small footprint individually, but five or six of them running simultaneously stack their base memory usage.

Realistic minimum: 2 GB for three to four lightweight services. 4 GB if the stack includes anything memory-intensive like Nextcloud with preview generation or a media server.

Database-heavy workloads

If your primary workload is a database instance serving queries to an application hosted elsewhere, most of your RAM budget goes to the database engine's buffer pool. PostgreSQL and MySQL both perform dramatically better when their working dataset fits in memory. When it does not, every query that misses the buffer pool hits disk, and the performance gap between serving data from RAM and reading it from disk is significant even on fast NVMe storage.

Realistic minimum: 2 GB for small to medium databases. 4 GB and up when the active dataset exceeds a few hundred megabytes. This is the workload type where upgrading RAM produces the most directly measurable performance improvement.

The Signs You Are Running Low

Linux does not always make memory pressure obvious. The system keeps running until it cannot, and by the time a process gets killed, the problem has usually been building for a while. Watch for these:

1. Swap usage climbing steadily. If free -h shows significant swap in use on a server that should have enough RAM, the kernel is already offloading memory pages to disk. Small amounts of swap activity are normal. Sustained swap usage under standard traffic means the workload exceeds available memory.
2. OOM killer entries in system logs. Search dmesg or /var/log/syslog for "Out of memory" or "oom-kill." Each entry means the kernel forcibly terminated a process because it could not find enough free memory. If the killed process was your database or web server, the site went down.
3. Sluggish response times that correlate with traffic volume. When memory is tight, the kernel reclaims filesystem cache aggressively. Disk I/O increases, database queries slow down, and page load times spike. This happens gradually enough that it is easy to attribute the slowdown to something else.
4. Database performance degrading over time. If your database was fast after a restart but gets progressively slower as data grows, the working set may have outgrown the buffer pool. This is the most common RAM-related performance issue on VPS instances running web applications.

One thing worth checking early: not every provider provisions swap space by default. If your VPS has no swap partition or swap file, the OOM killer has no buffer at all. Creating a small swap file (1 to 2 GB) does not fix an undersized plan, but it gives the system a brief window to handle memory spikes instead of killing processes immediately.

Common Sizing Mistakes

Starting with the cheapest plan regardless of workload. A 512 MB plan is adequate for a reverse proxy or static site. It is not adequate for WordPress with a database. Saving a few dollars per month and running into OOM kills within weeks is a false economy.

Ignoring the database entirely. Many buyers size their plan around the application and forget that the database is sharing the same memory. A database with a tiny buffer pool performs as if it were running on much slower hardware, even if the CPU and storage are fast.

Assuming you can "just upgrade later." You probably can, but the upgrade path matters. Some providers allow in-place memory scaling with minimal downtime. Others require provisioning a new instance and migrating your data. Check how your provider handles plan changes before assuming the upgrade will be painless. The VPS evaluation guide covers what to look for in scalability and upgrade path before you commit.

Treating memory ballooning as normal. On a properly configured KVM VPS, the RAM allocated to your instance is yours. Some providers and some virtualization approaches use memory ballooning, where the hypervisor reclaims unused RAM from idle instances. If your VPS sometimes performs well and sometimes does not, and the pattern does not correlate with your own traffic, the underlying host may be overcommitted.

A Quick Reference for Plan Sizing

These are starting points, not hard limits. Monitor actual usage under realistic traffic within the first week and adjust from there.

Right-Size It, Then Monitor

Get the plan size roughly right, then monitor. Install htop or use free -h and vmstat regularly during the first week after deployment. If swap usage stays near zero and the OOM killer never fires, you are in the right range. If swap climbs under normal traffic, upgrade before the situation becomes an outage.

If you are still comparing providers, the providers directory includes plan details and community ratings across pricing, performance, reliability, and four other dimensions. Users who have run real workloads on these plans consistently report things the spec sheet does not: actual memory behaviour under their specific stack, whether in-place upgrades work as advertised, and how support handles resource-related tickets.

For buyers coming from shared hosting, memory management is the biggest operational difference. Shared hosting abstracts it away entirely. On a VPS, it is your responsibility, and getting familiar with your memory profile early prevents the kind of surprise that takes a production site offline.