A database can get faster after adding more RAM, even when you do not change the database’s own memory settings.

At first, that sounds wrong.

If the buffer pool is already large enough, why should another 32 GB or 64 GB of RAM make any difference?

The reason is that the database is not the only thing using memory.

On Linux, unused RAM is often used as page cache . The kernel keeps recently accessed file data in memory so it does not have to read the same blocks from disk again.

That can include things around the database such as:

  • table files
  • indexes
  • WAL or log files
  • filesystem metadata
  • recently accessed data that is not currently inside the database’s own cache
Table filesIndexesWAL / logsFS metadataRecent dataLinux page cacheMemory (RAM)

So the path can change from this:

Reads hit diskQueryDatabaseFilesystemDiskReads hit RAMQueryDatabaseLinux page cacheMemory

The database itself may still be configured exactly the same.

What changed is that the operating system now has more space to keep useful filesystem data in RAM.

That means fewer physical reads, less storage latency, and sometimes noticeably better query performance.

This is also why seeing very little “free” memory on a Linux database server is not automatically a problem.

Linux prefers to use available memory instead of leaving it completely idle — that’s exactly what the buff/cache column in free is showing you.

The useful distinction is:

Databaseits own memory managementLinux page cachea separate caching layerPhysical RAM

The database has its own memory management. The operating system has another layer of caching around it.

Both can affect performance.

There is one important nuance though.

Not every database relies on the OS page cache in the same way. Postgres deliberately keeps shared_buffers modest and leans on the OS to cache the rest — the official guidance is famously “don’t just set it to all your RAM.” MySQL’s InnoDB goes the other way: it commonly runs with innodb_flush_method=O_DIRECT specifically to avoid caching the same page twice, once in its own buffer pool and once in the kernel’s page cache. And a database like Redis barely touches this problem at all, because it keeps the working set in its own process memory rather than leaning on the filesystem layer underneath it.

So adding RAM is not a universal database tuning trick.

But when the workload still depends on filesystem caching, extra RAM can improve performance even if the database itself never asked for more memory.

That is the interesting part.

Sometimes the performance gain is not coming from the database at all.

It is coming from the layer underneath it.

If you want to see why that layer behaves this way in the first place, see Why the OS Never Lets Your Process Touch Real Memory — the same page-cache mechanism described here is one consequence of that deeper virtual memory design.

References