How Much RAM Does Postgres Need on a Small VPS?
How much RAM does Postgres actually need? Here is how to size and tune Postgres memory on a small VPS so it runs fast without starving your app.
Postgres needs far less RAM than people assume, and how much depends on your working set, not your total data size. A small production database serving a side project runs comfortably in one to two gigabytes of dedicated memory. The number that matters is whether your frequently accessed data fits in memory, not how many gigabytes sit on disk. And the most common Postgres performance problem on a small VPS is not too little RAM, it is default settings that assume the database owns the whole machine when it is actually sharing it with your app.
What actually uses Postgres memory?
Postgres memory splits into a few buckets, and understanding them is how you size sensibly. shared_buffers is the cache Postgres keeps of frequently read data, and it is the big lever. work_mem is per-operation memory for sorts and joins, allocated per query, so a busy database with many concurrent queries multiplies it. The operating system also caches file data, which Postgres relies on, so the OS page cache effectively acts as a second layer of database cache.
The key insight: Postgres does not need to hold your entire database in RAM. It needs to hold your working set, the rows and indexes you actually touch often. A hundred-gigabyte database where queries only hit the recent, hot rows might run fine in two gigabytes of cache because the cold data is rarely read. Size for the working set, not the disk footprint. This is the same evidence-based approach I take to sizing a VPS for your workload generally.
The default that wrecks small boxes
Out of the box, Postgres ships with conservative defaults, and the bigger risk on a small VPS is the opposite: settings that let Postgres assume more memory than the box can spare when it shares hardware with your app. If you set shared_buffers to a large fraction of total RAM while your app also wants memory, the two starve each other and the box swaps. Swapping is death for database latency.
The rule for a shared box: tune Postgres for the memory you have actually allotted it, not the machine total. If the app needs a gigabyte and the box has four, Postgres gets tuned as if it lives on a three-gigabyte machine. Cap the app's memory too, with container limits, so neither side can consume the whole box. This resource-boundary discipline is exactly why I wrote should Postgres share the app's box or get its own: colocation is fine, but only if you set the limits.
How do I tune Postgres on a small VPS?
Start from your allotted memory and set a few parameters deliberately rather than accepting defaults:
shared_buffers: roughly a quarter of the memory you have assigned to Postgres. Not a quarter of the box if the box is shared.work_mem: keep it modest, and remember it is per operation. A high value times many concurrent queries can blow past your budget fast.effective_cache_size: an estimate you give the planner of total cache available, including OS page cache. It does not allocate memory, it informs query plans, so set it to reflect reality.max_connections: keep it low and use a connection pooler. Each connection costs memory, and hundreds of idle connections waste RAM a small box cannot spare.
A connection pooler like PgBouncer in front of Postgres is the highest-leverage addition on a small box. It lets a handful of real database connections serve many app connections, which keeps memory flat as traffic rises.
Signs you genuinely need more RAM
Tune first, then judge. The real signal that Postgres needs more memory is a low cache hit ratio combined with disk-read-bound queries: Postgres is constantly going to disk because the working set does not fit in cache. You can read the cache hit ratio from Postgres's own statistics. If it is high and queries are still slow, the problem is missing indexes or bad queries, not RAM, and a bigger box will not help.
If the hit ratio is low and the box is swapping under normal load, then you have a real capacity problem and it is time to add memory or split the database onto its own box, which is one of the signals in when to upgrade your VPS. But reach that conclusion from the numbers, not from a guess. Most small-box Postgres slowness is a tuning or indexing problem wearing a memory costume.
Run Postgres on a right-sized, well-tuned HostSSH box, set the memory parameters against what you actually allotted it, put a pooler in front, and it will serve a real product on modest RAM. The database is rarely the reason you need a bigger machine. The defaults are.