A rightsizing review halves a database instance from 128 GB to 64 GB of RAM because the engine's resident set is only 40 GB and the memory dashboard shows 45% used. Reads were almost all served without touching disk before. What happens after the change?

What is being tested

Whether you know that free memory on a database host is not idle memory. The operating system spends it on page cache, and the page cache is the reason the read path never reached a disk.

The mechanism

A storage engine reads through the kernel's page cache. Pages touched recently stay resident, so a query that hits a cached page costs microseconds of memory access instead of a storage round trip. With 128 GB of RAM and a 40 GB resident set, roughly 80 GB was holding hot pages. Halve the host and that cache falls to perhaps 20 GB.

The working set did not change, so every read that used to land in the missing 60 GB of cache now becomes a storage read. A table that was served entirely from memory in production now generates thousands of read operations a second. On a managed database those operations are metered, and on a self-managed instance they consume provisioned IOPS and burn through burst credits.

What it looks like, in order

• Minute 0: the instance restarts smaller. The cache is empty, so almost every read goes to storage and p99 is at its worst.
• Minutes 1 to 30: the cache refills to its new, smaller size. Latency improves and stops improving well short of where it started.
• The steady state: read IOPS an order of magnitude higher, p99 two to five times the old value, and a storage line that has absorbed most of the compute saving.
• The month-end invoice: compute down, storage IO up, net saving much smaller than projected, and a latency regression nobody connected to the change.

Why the other options fail

• "Nothing measurable changes." This is the mistake the dashboard invites. The engine did not allocate that memory, which is exactly why it was available for cache. Unused and unallocated are different states.
• "Writes become the bottleneck." Write buffers and log space are sized by configuration, not by whatever RAM is left over, so halving the host does not shrink them unless you also change the settings. Writes degrade later, as a second-order effect of the extra read IO competing for the same device.
• "The optimiser picks worse plans." Planner memory settings are explicit parameters. They would need editing to change, and the instance size alone does not rewrite them. This is the plausible-sounding option that confuses configuration with capacity.

The decision rule

Never size a database from resident set size. Size it from cache hit ratio and read IOPS: shrink only while the buffer or page cache hit rate stays above the level where storage reads are rare, and stop when read operations begin to climb. Record the IO rate before and after, because that is where the money actually went.

When this is the wrong answer

For a stateless service with no local cache, free memory genuinely is waste, and halving it is the cheapest saving available. The rule applies to anything that caches: databases, search indexes, object caches and build servers with warm artifact directories.