The primary focus when selecting memory for a highly available system is stability. It's no accident that most, if not all, server-class RAM is of the error-correcting variety. There are a few other things to consider that may not appear obvious at first glance.

Due to the multi-core nature of our CPUs, the amount of addressable memory may depend on the core count. In addition, speed, latency, and parity are all considerations. We also must include the number of channels reported by each CPU; failing to match this with an equal count of memory sticks can drastically degrade performance.

This recipe will help ensure our server remains fast and stable by considering memory options.

Some of the decisions we will make depend on the capabilities of the CPU. Make sure to read through the Picking a processor recipe before continuing. If we have a PostgreSQL database available, there's also a query that can prepare us for selecting the most advantageous count of memory modules. It's also a very good idea to complete the Sizing storage recipe to get a better idea for choosing an amount of memory.

We can collect some of the information we want from PostgreSQL if we have an install already. Follow these steps if there's an existing database instance that we can use:

1. Execute the following query to obtain the size of all databases in the instance:

SELECT pg_size_pretty(sum(pg_database_size(oid))::BIGINT) 
  FROM pg_database; 

2. Multiply the result by eight.

If we don't have an existing database, we should use a size estimate of the database install after 3 years. Refer to the Sizing storage recipe to obtain this estimate. Then, perform the following steps:

1. Divide the current or estimated database storage size by ten to obtain the minimum amount of memory.
2. Multiply our ideal CPU chip count by four to get the memory module count.
3. Divide the minimum memory amount by the module count to get the minimum module size.
4. Round up to the nearest available memory module size.

The important part of this recipe is starting with a viable estimate of the database size. Since a lack of RAM usually won't cause the database to crash or operate improperly, we can use looser guidelines to obtain this number. Hence, 3 years down the road, an existing database install could be eight times larger than its current size. We use eight based on previous assumptions that the database roughly doubles in size every year.

Why do we then divide that number by ten? Our goal here is to maximize the benefit of the OS-level cache, which will consume a majority of our RAM. This estimate gives us a value that is ten times smaller than the space our database consumes. At this scale, data that is frequently fetched from disk is likely to be served from memory instead. The alternative is read latency due to insufficient memory for disk caching.

Most current CPUs are quad-channel, and thus operate best when the number of modules per processor is a multiple of four. Assuming we previously determined how many processor cores would be ideal for our system in the Picking a processor recipe, we automatically know the most efficient memory module count. Why do we multiply by four, regardless of how many memory channels the CPU has? Adding more memory modules is not wasted on chips with fewer channels, and provides a possible upgrade path.

Dividing the memory amount by the module count gives our minimum module size. RAM comes in many dimensions, and our calculation is not likely to match any of the available dimensions for purchase, so we need to round up. Why not round down? The operating system will utilize all available RAM to cache and buffer important data. Unless the greater amount is extremely expensive in comparison, any excess memory will not be wasted.

Imagine we have a 200 GB PostgreSQL installation, and chose to buy a single CPU chip. If we follow the preceding procedure, we would want at least 20 GB of RAM distributed over four RAM chips. Since 20/4 = 5, we would likely want four 8 GB RAM chips, or a total of 32 GB. This is actually a fairly good starting value in general, and allows our database to grow before 10% of its current size is greater than 32 GB.

We didn't focus on memory speed, timings, or latency here. Timing and latency can affect performance, but our primary focus is stability. We're always free to order faster or better memory as our budget allows.

Memory speed, on the other hand, is a more visible factor. Memory speed works with a multiplier to match the highest compatible motherboard bus speed. This directly controls how quickly the CPU can utilize available RAM. Before buying memory, research the stated clock speed and try to match it with one of the faster settings compatible with both the CPU and motherboard.

For example, DDR4-3200 is twice as fast as DDR4-1600 since it operates at 400 MHz, as opposed to 200 MHz. Database benchmarks would be vastly different between these two memory speeds, even with the same CPU. Fast memory means that PostgreSQL can make more immediate use of cached data and produce results more quickly.