Add up the three consumers first
Both tiers are AMD EPYC 7543P, 32 cores / 64 threads, 2.8–3.7 GHz. 128GB is $449 a month. 256GB is $599 a month. Memory on both is DDR4-3200 ECC RDIMM. You choose it when you order. Modules cannot be added later. Decide whether the primary database and the cache share this machine before you pay, because there is no third RAM tier to move to afterward.
On one host, RAM is split across at least three consumers. The first is the operating system, page cache, and connections, including the admin processes you use over SSH.
The second is the hot data the database should keep resident: for MySQL that is mostly the InnoDB buffer pool; for PostgreSQL it is shared_buffers plus the page cache the OS keeps for it.
The third is Redis, or another cache, under maxmemory. If the application also runs here, subtract its resident set as well.
Add those three, leave headroom, then compare the total with 128 and 256. Do not treat on-disk database size as the RAM requirement. A 400GB data directory can have only a few tens of gigabytes that queries actually touch. The reverse is also common: a small directory whose cache must hold most of the object set will outgrow 128GB first. Size the hot set and the cache target, not the directory total.
Both tiers have ECC, and both have the same core count. The extra $150 a month buys RAM only. 256GB does not add cores, and 128GB does not save CPU.
This note is for MySQL, PostgreSQL, and Redis on Linux. If you select Windows Server, size SQL Server memory separately. Do not copy the buffer-pool ratios below onto Windows. On Linux you change the settings over SSH. The login method is the same on both tiers.
When 128GB is enough
128GB is enough when several things are true together. The buffer pool covers the hot set and the hit rate is already steady. Redis holds sessions, hot keys, or one bounded object cache, on the order of 8GB to 24GB, and the eviction rate is acceptable. The OS, connections, and any app on the same host still have about 16GB to 24GB. Over the next half year the hot set will not double, and you are not moving a second large in-memory service onto this box.
Treat this as a worksheet, not a capacity promise. On 128GB, leave about 20GB for the OS and connections. If Redis is planned at 16GB, about 90GB remains for the database. A MySQL buffer pool can start between 64GB and 80GB, with room for page cache and on-disk sorts. If Redis is only a few gigabytes, the pool can sit nearer 80GB. If Redis already needs 24GB, do not push the pool past 80GB.
PostgreSQL usually sets shared_buffers lower than a MySQL buffer pool. A common start is around a quarter of physical RAM, with the OS page cache holding the rest.
The same hot set can therefore stay on the 128GB tier, as long as concurrent sorts and hash aggregates do not multiply work_mem into a large peak.
One query can contain several sort nodes, then you multiply by the number of queries running at once. 64MB times a few dozen concurrent operations usually still fits. Hundreds of megabytes of work_mem times a hundred concurrent operations will consume the free space on 128GB.
When to choose 256GB
Any one of the following points to 256GB. You want a buffer pool around 80GB and a Redis of several tens of gigabytes at the same time.
On the current machine, database RSS plus cache RSS is already near or above 90GB.
PostgreSQL runs many concurrent sorts, and work_mem times that concurrency fills the headroom.
Besides the primary and Redis, a search engine or another heap-heavy service must live here. The app is not split off, and the app itself needs more than 10GB.
For a 256GB worksheet, leave 24GB to 32GB for the OS and connections. If Redis needs 32GB to 48GB, the buffer pool can still land between 120GB and 160GB. That is a start. After go-live, pull the caps back using hit rate, temp files, and Redis evictions. Do not assign about 90 percent of physical RAM to the buffer pool and also run a large Redis. When both expand, the host starts swapping, and the stall is harder to read than a cache miss that falls through to disk.
The price gap is $150 a month. A quarter is $1,347 versus $1,797. Half a year is $2,694 versus $3,594. A year is $5,388 versus $7,188. The term only multiplies the monthly total. Choosing 256GB does not add a discount. Moving a database later because RAM was short usually costs more than that $150. If current use already sits near the 128GB waterline, order 256GB. If the hot set is concentrated, the hit rate is high, and the cache is still 8–24GB, stay on 128GB.
Match the tier to your own numbers
Fill the table with figures from production or from the previous host. Any row that lands in the right column means you should plan for 256GB. If all five rows land on the left, 128GB covers this order.
| What you can measure | Closer to 128GB | Closer to 256GB |
|---|---|---|
| Hot set | The buffer pool covers it and the hit rate is steady | Hot data itself is near or above 100GB |
| Redis / cache | 8–24GB of hot keys or sessions | Tens of GB more, and the buffer pool is also large |
| Connections and sorts | Connection count is bounded; sorts rarely spill | work_mem times concurrency fills the headroom |
| Who else is on the host | Mostly the primary and this one cache | Also the app, search, or a second memory service |
| The next six months | The hot set will not double | Current use is already near 90GB |
A high hit rate, acceptable evictions, and a concentrated hot set belong on 128GB. If you are using disk to stand in for RAM, or Redis is evicting keys you still need, choose 256GB. When the numbers are fuzzy, take resident memory on the previous host, multiply by 1.3 for growth, and compare with 128 and 256. Under about 100GB, the 128GB tier holds this plan. Past 100GB, order 256GB.
Cap the database and the cache after install
After the tier is chosen, write explicit caps for the database and the cache. Without caps, InnoDB and Redis each follow their own defaults and compete for the same physical RAM.
-
1
Write down three numbers
Database RSS, Redis
used_memory, and memory the OS still has free. For MySQL, read the buffer-pool hit rate. For Redis, readused_memoryandevicted_keys. For PostgreSQL, read cache hits and temp files. -
2
Cap the pool and maxmemory separately
On a shared host, keep the InnoDB buffer pool around 60 to 70 percent of physical RAM unless Redis is small. Set Redis
maxmemoryand an eviction policy. Both caps need to exist at once. -
3
Leave a gap for page cache
The sum of the buffer pool and the Redis cap should stay under physical RAM minus OS and connections. On 128GB, try a combined cap near 100GB. On 256GB, try a combined cap near 210GB.
-
4
Look again after a week
If swap keeps climbing, the caps are too high. Shrink the buffer pool or Redis, then watch the hit rate. A read that reaches disk is not, by itself, proof that the RAM tier was wrong.
A buffer pool above about 80 percent of physical RAM plus a large Redis will push the host into swap. Add the two caps, confirm they still fit, then restart the services.
Extra disks do not add RAM
The default disks are 2 × 1TB NVMe, with no hardware RAID. Each drive is attached on its own, and usable capacity is 2TB. When the hot set does not fit in RAM, reads land on those drives. NVMe absorbs the misses. Latency is still higher than a memory hit. An extra 2TB drive is $79 a month, up to two drives, still direct-attach. That adds capacity, not memory modules. Where to put data files versus backups is a disk decision. Do not substitute “add another drive” for the 256GB tier.
Bandwidth does not fill a buffer pool either. The default port is 250M, unmetered. 1G adds $250 a month and 2G adds $750. That changes egress rate. Traffic between the primary and a local Redis stays on loopback and does not consume that port. RAM and bandwidth are separate line items. If backups must leave the machine, judge 250M against that transfer. That is a different choice.
After the RAM tier is set, decide how the two direct-attach drives hold data. They are not hardware RAID. See the two-disk note.
How this maps onto the two servers
Once the hot set, cache, and headroom are added up, the order form has these two machines. 128GB is $449 a month. 256GB is $599 a month.
The CPU on both is EPYC 7543P, 32 cores / 64 threads, 2.8–3.7 GHz. Memory on both is DDR4-3200 ECC RDIMM, chosen at order time, with no modules added later.
The servers are in Tokyo, Japan. On Linux you SSH in and edit the buffer pool and maxmemory. There is no setup fee.
Amount due is the monthly total times the number of months. Monthly, quarterly, semiannual, and annual terms do not add a discount. Options on this host, including extra disks and bandwidth, are prepaid on the same term.
If the sum is already past what 256GB can hold comfortably — a large buffer pool, a large cache, a search heap, and the application all resident — do not force them onto one 256GB server. Split the cache or the search service onto a second machine. That is clearer than writing every cap to the ceiling. This note only chooses between the two tiers you can order.
Choose RAM, then install the database and cache
128GB is $449 a month. 256GB is $599 a month. RAM is chosen when you order. Servers are in Tokyo, Japan. You can order before you sign in.