Hyper: keep the working set in RAM

What Hyper is really for

A database is fast when the data it needs is already in memory. On smaller plans, a working set larger than RAM means reads fall through to disk; even on NVMe-backed storage that is a microseconds-to-milliseconds jump, and it shows up in tail latency. Hyper gives you 32 GB so that a database in the tens of gigabytes can keep its hot tables and indexes resident.

The second job for Hyper is building large codebases. Eight cores and plenty of memory let you link big binaries in parallel without the OOM killer picking a victim halfway through.

Postgres on 32 GB

These are starting values for a dedicated database server. Tune from measurements, not from this page, but this is a sane first boot:

# /etc/postgresql/16/main/conf.d/max.conf
shared_buffers = 8GB
effective_cache_size = 24GB
work_mem = 32MB
maintenance_work_mem = 1GB
max_connections = 120
max_wal_size = 8GB
checkpoint_completion_target = 0.9
random_page_cost = 1.1
effective_io_concurrency = 200
huge_pages = try

effective_cache_size is a hint, not an allocation: it tells the planner how much the OS page cache is likely to hold, which makes index scans look as cheap as they really are. effective_io_concurrency lets bitmap heap scans issue many reads at once, which is where NVMe-backed storage pulls ahead of older disks. The database tuning guide explains each of these in more depth.

Huge pages, briefly

With 8 GB of shared buffers, the kernel would otherwise track around two million 4 KB pages per backend mapping. Huge pages cut that overhead and make memory access more predictable.

# 8 GB / 2 MB pages = 4096, plus a little slack
echo 'vm.nr_hugepages = 4300' > /etc/sysctl.d/60-hugepages.conf
sysctl --system
grep Huge /proc/meminfo

Reserve them right after boot, before memory fragments, and restart Postgres to pick them up.

MySQL and MariaDB

The same principle applies with a different knob. Give InnoDB most of the memory on a dedicated box:

[mysqld]
innodb_buffer_pool_size = 22G
innodb_buffer_pool_instances = 8
innodb_log_file_size = 2G
innodb_flush_method = O_DIRECT
innodb_io_capacity = 4000

O_DIRECT avoids caching pages twice, once in the buffer pool and again in the page cache, which matters when memory is the reason you bought this size.

Planning the 200 GB

A local dump is a convenience for a quick rollback, not a backup. Take scheduled backups in the portal, push logical dumps off-box, and test a restore now and then. The backups and snapshots guide has a routine that takes ten minutes to set up.

Large builds

For monorepos and big C++ or Rust trees, Hyper lets you run -j8 with enough memory per job that linking does not become the failure point. Put compiler caches such as ccache or sccache on local disk and give them a generous size; 30 GB is reasonable here and turns rebuilds into mostly cache hits.

ccache --max-size=30G
ccache --show-stats

Smaller or split

• CPU-heavy but memory is half used: Warp keeps six cores for $6 less.
• Database and app competing on one Hyper: split them. The app tier rarely needs more than a Turbo.
• Outgrowing Hyper: there is no larger single plan. Separate reads onto a replica, or partition data across servers.

Price

Hyper is $28 a month or $280 a year, billed in US dollars by our checkout. No setup fee. Same 1 Gbps unmetered port and dedicated IPv4 as the smallest plan, because the network does not get rationed by size.