HiMem VMs Explained: When More RAM Matters Than More CPU

HiMem VMs are memory-forward virtual machines that provide more RAM per vCPU than a balanced VM shape, making them useful when memory pressure appears before compute pressure.

The decision is not simply “RAM or CPU.” It is whether the workload is waiting for compute or struggling to keep its active working set in memory. A database can have comfortable CPU usage and still perform poorly under memory pressure. A multi-container application can restart services even when the processors are mostly idle. Conversely, a build worker can have plenty of free RAM while CPU remains the real constraint.

Raff Technologies supports 3,000+ customers and 15,000+ VMs. In Raff infrastructure reviews, the useful signal is not a single high-memory percentage; it is repeated memory pressure combined with swap activity, reclaim stalls, out-of-memory events, container restarts, or application behavior that improves when more RAM is available.

This guide is part of the VM Machine Classes cluster. Use it when the question is specifically whether a workload needs a higher memory-to-vCPU ratio. For current Raff General Purpose sizes and prices, use Raff General Purpose VM Plans.

HiMem VMs change the memory-to-vCPU ratio

A HiMem VM is not necessarily a different kind of processor or a separate architecture. It is a resource shape that gives the workload more memory relative to available CPU.

That distinction matters because VM size and VM class answer different questions:

• vCPU count determines how much parallel compute is available to the guest;
• memory capacity determines how much active data and how many processes can remain resident in RAM;
• CPU allocation model determines whether compute is shared or dedicated;
• storage capacity and behavior determine how durable data grows and how the application handles reads and writes.

A workload can need more memory without needing more CPU. For example, moving from 2 vCPU / 4 GB RAM to 2 vCPU / 8 GB RAM doubles memory while keeping the same vCPU count. That is a memory-shape change. Moving from 2 vCPU / 4 GB to 4 vCPU / 4 GB changes compute without increasing memory.

The machine-class decision should therefore begin with the constrained resource rather than the largest number in the pricing table.

Memory pressure has different symptoms from CPU pressure

CPU saturation and memory pressure can both make an application feel slow, but they leave different evidence.

Linux exposes memory pressure separately from raw memory usage. Pressure Stall Information (PSI) can report how much time tasks are stalled because memory is unavailable, and the kernel can invoke the OOM killer when it cannot reclaim enough memory to continue normal operation.

This is why a fixed rule such as “upgrade at 80% RAM” is too crude. High memory utilization can be healthy when the operating system is using available RAM for useful cache. The stronger evidence is pressure plus impact: reclaim stalls, sustained swap, OOM kills, failed allocations, restarts, or user-visible slowdown.

In Raff infrastructure work, we treat memory utilization as context rather than a verdict. The upgrade becomes defensible when the workload repeatedly loses stability or latency headroom because it cannot keep enough active state in RAM.

Databases often need memory before they need more cores

Databases are a common reason to choose a memory-forward VM, but more RAM is not a universal database fix.

PostgreSQL, MySQL, and similar systems use memory for buffers, caches, connections, query operations, and supporting processes. The application host may also run a reverse proxy, API process, worker, monitoring agent, and operating-system cache. When several of those components share one VM, the total working set can become the constraint before CPU does.

A higher-memory shape is worth evaluating when:

• the database and application compete for RAM;
• swap activity appears during normal load;
• larger queries or maintenance jobs create memory pressure;
• connection growth materially increases the memory footprint;
• cache effectiveness or working-set size is constrained by available RAM;
• OOM events or service restarts occur under otherwise moderate CPU load.

Do not move to a HiMem shape merely because the workload contains a database. Slow queries may come from missing indexes, poor query plans, lock contention, storage waits, or inefficient application access patterns. If CPU remains low and memory pressure is absent, more RAM may not change the bottleneck.

The clean decision is to separate database tuning from VM sizing. Fix avoidable query and schema problems first; then add memory when the measured working set and operational headroom justify it.

If the application and database now need different recovery, maintenance, or scaling boundaries, Separate App and Database Server may be a better next step than continuing to enlarge one VM.

Containers and multi-service VMs amplify memory demand

A single self-hosted product can represent several running processes.

A Docker Compose deployment might contain:

• an application service;
• PostgreSQL or MySQL;
• Redis or another cache;
• a queue;
• one or more workers;
• a reverse proxy;
• monitoring or logging agents;
• scheduled jobs.

Each service can look modest in isolation while the combined host becomes memory-constrained. Runtime heaps, database buffers, caches, container overhead, package updates, and deployment processes all compete for the same physical RAM assigned to the VM.

This is why a stack may install successfully on a small VM but become unstable later. Installation tests a narrow moment. Production adds concurrency, larger datasets, background work, logs, deployments, and temporary memory peaks.

A memory-forward VM is useful when the services should intentionally remain on one host and additional RAM restores operating headroom. It is less useful when the services have already developed different scaling or recovery requirements. In that case, service separation can be the cleaner architecture.

Use Cloud Server Performance Bottlenecks when CPU, memory, disk I/O, and application dependencies need to be diagnosed together.

The decision framework separates memory capacity from compute capacity

Use the following framework before choosing a HiMem VM.

The decision can be reduced to four questions:

1. Is the workload actually under memory pressure? Look beyond percentage-used metrics.
2. Does memory pressure align with a real outcome? Check latency, restarts, OOM events, swap, queue behavior, or database symptoms.
3. Would more RAM solve the constraint without adding unnecessary CPU? If yes, a memory-forward shape is appropriate.
4. Should the services still share one VM? If not, architecture may matter more than a larger memory ratio.

A HiMem VM is therefore a targeted upgrade, not a premium default.

Raff offers several memory-forward General Purpose shapes

Raff’s current General Purpose lineup is shared-vCPU compute with multiple CPU-to-memory ratios. The live pricing page does not present “HiMem” as a separate product family; instead, users can choose higher-memory shapes inside the General Purpose ladder.

As of August 10, 2026, examples include:

The 2 vCPU / 8 GB and 4 vCPU / 16 GB shapes are useful examples of choosing more memory without proportionally increasing compute. The 4 vCPU / 8 GB configuration is currently marked Popular and costs $30.99/month.

Raff offers a 2 vCPU / 8 GB / 160 GB General Purpose VM at $27.99/month for workloads that need a higher memory-to-vCPU ratio.

Every current Raff Cloud Server plan also includes a 3 Gbps public port, unmetered bandwidth, resize support, private networking, DDoS protection, browser console/root access, API and Terraform access, and monitoring.

Pricing changes faster than architecture guidance, so use the live Raff pricing page to confirm the current plan table before deployment.

Measure memory pressure before and after resizing

A memory upgrade should improve a workload outcome, not only lower a percentage on a dashboard.

Useful measurements include:

• available memory over time;
• swap usage and swap-in/swap-out activity;
• memory PSI on Linux where available;
• OOM-kill events;
• container memory limits and restart counts;
• application heap or garbage-collection behavior where relevant;
• database memory footprint and connection count;
• p95/p99 latency during pressure periods;
• queue depth or worker completion time;
• disk I/O wait, because swap and memory pressure can surface as storage activity.

Compare equivalent workload windows before and after resizing. If more RAM removes swap, OOM events, or pressure stalls but user-facing latency does not improve, another bottleneck may still be present. If memory pressure disappears and the workload becomes stable, the change was justified even if average CPU utilization remains unchanged.

Do not treat free RAM as wasted money automatically. Some headroom protects deployments, traffic variation, maintenance jobs, database working sets, and temporary process growth. The objective is not maximum utilization; it is stable operation at a cost the workload justifies.

More RAM matters when memory is the measured constraint

HiMem VMs are useful when the workload needs a higher memory-to-vCPU ratio, not because high-memory plans are inherently better.

Choose a memory-forward shape when memory pressure, swap, OOM events, container restarts, database working-set limits, or multi-service contention appear before CPU saturation. Choose more vCPU when compute is the constraint. Evaluate CPU-Optimized when sustained CPU predictability matters. Separate services when independent scaling or recovery is more valuable than a larger single VM.

For the parent decision, return to Cloud VM Machine Classes Explained. For current General Purpose sizes and pricing, continue with Raff General Purpose VM Plans. If the issue is CPU allocation rather than RAM, use Shared vs Dedicated vCPU.

Sources

• Linux Kernel: Pressure Stall Information
• Linux Kernel: Out Of Memory Handling
• Raff Pricing
• Raff VM