Best High Memory VPS in 2026 — 64GB+ Tested for Elasticsearch, Redis & JVM Workloads

The Elasticsearch Cluster That Started This

Six months ago I was migrating a client's search infrastructure off AWS. Three Elasticsearch data nodes, 64GB RAM each, $590/month total on r6g.2xlarge instances. The client wanted the same performance at one-third the cost. I started testing VPS providers.

First discovery: "64GB RAM" does not mean "64GB for Elasticsearch." The KVM hypervisor takes a cut. The kernel reserves memory. Some providers run balloon drivers that silently reclaim memory when the host gets busy. On one provider, my Elasticsearch heap was sized at 31GB expecting 33GB for Lucene's file cache. During a host traffic spike, the balloon driver stole 1.2GB. Query latency doubled. No alert — took two days to diagnose.

Second discovery: memory bandwidth varies by nearly 2x across providers offering identical RAM. An ES aggregation scanning 8GB completed in 340ms on one provider and 620ms on another. Same data, same query, same JVM. The difference was 42 GB/s versus 22 GB/s STREAM bandwidth. This page exists because those two findings changed everything about how I evaluate high-memory VPS.

Allocated RAM vs. Usable RAM — The Numbers Nobody Publishes

Every provider advertises allocated RAM. None publish usable RAM. I measured each 64GB-class plan with free -m on a fresh OS install, confirmed via /proc/meminfo:

The overhead comes from three sources: KVM hypervisor (200-500MB for virtio drivers and device emulation), Linux kernel reservations (page tables, slab caches — about 1-3% of total RAM), and balloon drivers. The virtio-balloon module lets the hypervisor reclaim "unused" memory from your VPS and hand it to other tenants. For Elasticsearch with a pre-allocated JVM heap, balloon reclaims shrink Lucene's file cache, pushing queries from RAM to NVMe — the difference between 50ms P99 and 200ms P99.

Check for balloon drivers: dmesg | grep -i balloon and lsmod | grep virtio_balloon. You can blacklist it, but the cleaner solution is choosing a provider that does not use balloon drivers on high-memory plans — on this list, that means Hetzner's dedicated CCX line.

Memory Bandwidth: The Hidden Bottleneck

If you only read one section of this page, read this one.

Capacity tells you how much data fits in RAM. Bandwidth tells you how fast the CPU reads it. For Elasticsearch aggregations, Redis SCAN, Spark shuffles, Pandas groupby — bandwidth is the bottleneck. You can have 128GB and still be slow at 15 GB/s. I ran STREAM across all five providers. Not close:

Hetzner's STREAM Triad of 42.1 GB/s is nearly double Contabo's 22.0 GB/s. In real workload terms, here is what that means:

• Elasticsearch aggregation scanning 8GB of indexed data: 340ms on Hetzner vs. 620ms on Contabo. Same indices, same query, same heap settings.
• Redis SCAN iterating 50 million keys: 4.2 seconds on Hetzner vs. 7.8 seconds on Contabo.
• Pandas groupby on a 12GB DataFrame: 28 seconds on Hetzner vs. 51 seconds on Contabo.
• JVM garbage collection (full GC on 31GB heap): 1.8 seconds on Hetzner vs. 3.1 seconds on Contabo. The GC must scan the entire heap, so bandwidth directly determines pause duration.

Why the difference? CPU generation. Contabo runs AMD EPYC 7002 (DDR4-3200). Hetzner runs EPYC 9004 (DDR5-4800). Memory controller bandwidth roughly doubled between generations. This is hardware-level — no plan change fixes it. The takeaway: if your workload rarely scans large memory regions (single-key Redis lookups, JVM apps with small working sets), bandwidth does not matter and Contabo's price advantage holds. If you run aggregations, analytics, or large GC heaps, Hetzner's 2x bandwidth is worth the premium.

NUMA Topology — Why Some 64GB VPS Instances Are Slower Than 32GB Ones

This explains a pattern I kept seeing: same provider, same plan, same config, but 15-25% variance in memory performance between different VPS instances. NUMA (Non-Uniform Memory Access) means each CPU socket has its own RAM. Local memory access: ~80 nanoseconds. Remote memory (other socket): 130-150 nanoseconds — a 60-90% penalty. When a hypervisor splits your 64GB across two NUMA nodes, performance becomes inconsistent. Run numactl --hardware to check:

$ numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3
node 0 size: 32168 MB
node 1 cpus: 4 5 6 7
node 1 size: 32168 MB
node distances:
node   0   1
  0:  10  21
  1:  21  10

Distance 21 (versus 10 for local) means remote access is 2.1x slower. I measured 1.8s full GC on single-NUMA versus 2.4s on split-NUMA with identical 31GB heaps. Redis is worse — single-threaded, so if the process runs on node 0 but half the data lives on node 1, every access to that half pays the penalty. 15% higher P99 latency on split-NUMA instances.

Which providers consistently gave me single-NUMA-node placement?

• Hetzner (CCX dedicated): Single NUMA node on all 8 instances I provisioned. Their dedicated CPU plans pin your vCPUs to a single socket.
• DigitalOcean (Memory-Optimized): Single NUMA node on 6 of 7 instances. The one exception was a 128GB instance that was necessarily split.
• Kamatera: Mixed. 4 of 6 instances were single-node. Their support confirmed they do not guarantee NUMA topology.
• Vultr: Mixed. 3 of 5 instances were split. Destroying and recreating sometimes got a single-node instance.
• Contabo: Split NUMA on 4 of 5 instances. Their high-density hosting model makes single-node placement less likely.

Fix options: numactl --interleave=all (evens out access, but does not eliminate the penalty), or destroy and reprovision until you get single-node placement. With hourly billing, this costs minutes and cents.

#1. Contabo — Most Raw GB Per Dollar (If Bandwidth Doesn't Matter)

This sounds contradictory after two sections on bandwidth and NUMA: Contabo is still my number one pick for most high-memory use cases. Most high-memory workloads are not bandwidth-sensitive. Redis single-key lookups, JVM apps with Young Gen-dominated allocation, PostgreSQL OLTP reading 8KB pages from shared_buffers — bandwidth is irrelevant for all of these.

I ran Redis serving 50,000 GET/s on Contabo's VPS XL for three months. Average latency: 0.18ms. P99: 0.42ms. Within 5% of Hetzner. At $54.99/month for 60GB, that is 4.6x cheaper per GB than DigitalOcean. Where Contabo falls apart: Elasticsearch aggregations, large SCAN operations, frequent full GCs, and in-memory analytics. If your workload scans more than 1GB of contiguous memory repeatedly, the 22 GB/s bandwidth bottlenecks you. Read our full Contabo review.

#2. Kamatera — Only Provider That Goes to 512GB

When you need more than 96GB on a single instance — a production ES node with 100GB+ Lucene file cache, a 200GB Redis graph dataset, an in-memory database like VoltDB — Kamatera is the only VPS-tier provider that scales to 512GB. The custom configuration model lets you independently set CPU (1-104 cores), RAM (1-512GB), and storage (20-4TB). A 128GB / 4 vCPU build works for pure memory workloads. A 64GB / 32 vCPU build works for concurrent ES query processing.

I tested 128GB / 8 vCPU dedicated for a single-node Elasticsearch instance with an 800GB index. 31GB heap, 97GB file cache. Indexing: 4,200 docs/s. Search P99: 280ms on complex aggregations. STREAM Triad of 34.6 GB/s sits between Hetzner and Vultr. The 30-day free trial ($100 credit) matters here — at $400+/month, verify your workload performs before committing. See our Kamatera review.

#3. Hetzner — Fastest Memory Bandwidth I Measured

Hetzner's shared CX plans max at 32GB, but their dedicated CCX line scales to 192GB and delivered the fastest memory bandwidth I tested. The CCX43 (64GB, 16 dedicated vCPU) runs AMD EPYC 9004 (Genoa) with DDR5-4800. STREAM Triad: 42.1 GB/s — within 80% of bare-metal, meaning minimal hypervisor overhead.

I deployed a 3-node ES cluster on CCX43 instances. Each node: 31GB heap, 33GB file cache, 16 dedicated vCPU. Indexing at 5,000 docs/s. Search results:

• Simple keyword search: 12ms P50, 28ms P99
• Date range + terms aggregation (scanning 2GB): 85ms P50, 140ms P99
• Complex multi-bucket aggregation (scanning 8GB): 210ms P50, 340ms P99
• Full GC pause (31GB heap): 1.8 seconds average, 2.1 seconds worst

The full GC matters: 1.8s on Hetzner vs. 3.1s on Contabo for the same 31GB heap. 1.3 extra seconds of Elasticsearch frozen — no queries, no indexing. On a search SLA, that is the difference between passing and failing P99.

CCX dedicated plans also solve NUMA and balloon problems. Pinned vCPUs on a single socket. No NUMA split, no balloon driver, no noisy-neighbor steal. That is why 63.2GB usable on 64GB is the highest I measured. Terraform and cloud-init mean fully scriptable deployments. Full details in our Hetzner review.

#4. Vultr — Best Geographic Coverage for Distributed Caching

Vultr fills one niche no other provider can: distributed high-memory deployments where geography determines performance. A single Redis node in New York adds 70ms round-trip for Los Angeles users. Vultr has 9 US datacenters (NY, LA, Dallas, Chicago, Seattle, Miami, Atlanta, Silicon Valley, Honolulu). Contabo has 3. Hetzner has 2.

Their High Memory plans are purpose-built: 64GB tier ($192/month) has only 4 vCPU. RAM-to-CPU ratio of 16:1 means you are not paying for compute you do not need. I deployed a 3-node Redis Cluster across NY, Dallas, and LA. Client latency from nearest DC: 0.3ms average. Cross-region replication lag: 8-12ms. STREAM Triad of 30.4 GB/s is mid-range but more than sufficient for single-key operations. Full API and Terraform provider for scripted multi-region deployment. See our Vultr review.

#5. DigitalOcean — When You Want Someone Else Managing the Memory

DigitalOcean is the most expensive per GB here. Memory-Optimized Droplets start at $63/month for 16GB. So why include it? Because for teams in production, the VPS is the smallest part of the problem. You also need memory monitoring, managed Redis, managed PostgreSQL, private networking, and load balancers. DigitalOcean bundles all of this.

I tested two Memory-Optimized Droplets (64GB each) running ES, connected via private network to app Droplets, with managed load balancer and Managed Redis. Total: ~$580/month. The equivalent self-managed on Contabo: ~$250/month plus 15-20 hours engineering time. STREAM Triad of 37.0 GB/s (AMD EPYC 7003) is second only to Hetzner. NUMA was single-node on 6 of 7 instances. 980 Mbps network — fastest measured. Read our DigitalOcean review.

Memory Bandwidth Benchmark Results

STREAM benchmark results from 64GB-class instances, compiled with GCC -O3, 80M elements, best of 10 iterations. Triad (combined read-multiply-add-write) is the most representative of real workload patterns.

The practical impact of these numbers, translated into real workload benchmarks I ran on each provider:

The last row is critical. Redis single GET — the most common production operation — shows no meaningful difference across providers. Single-key lookups are latency-bound, not bandwidth-bound. This is why Contabo remains the right default for most high-memory workloads.

Full Comparison Table

* Contabo's top shared plan is 60GB, not 64GB. Price shown is for the 60GB VPS XL.
** Hetzner shared plans max at 32GB. 64GB+ requires CCX dedicated plans.

Memory Sizing Guide by Workload

Conservative recommendations — running at 90%+ memory invites OOM kills, and under-provisioning costs more than an extra 16GB.

Use our VPS calculator to estimate your specific memory requirement based on your workload parameters.

How I Tested — And What Most Benchmarks Get Wrong

Most VPS benchmark sites run sysbench memory and report a single number. That tells you nothing about real high-memory performance. Here is what I actually measured:

• STREAM Benchmark: Compiled with gcc -O3 -march=native -fopenmp, 80M elements (640MB, exceeding L3 cache), 10 iterations. Triad results reported as they best represent real mixed read-write patterns.
• Intel MLC: Access latency at each memory hierarchy level. Reveals NUMA remote-node penalty on split instances.
• Redis: redis-benchmark with 50 parallel connections, 1M requests. Also 40GB dataset under sustained 50K ops/sec for 72 hours.
• Elasticsearch: 3-node cluster with Rally suite. Indexing throughput, search P50/P99, aggregation P50/P99, full GC pause. 31GB heap across all providers.
• Balloon monitoring: Custom script polling /proc/meminfo every 10 seconds for 30 days.
• NUMA consistency: 5-8 instances per provider, checked numactl --hardware on each.

Full benchmark data on our benchmarks page.

Frequently Asked Questions