16 September 2026

Postgres on a two-core VPS: what actually matters

A small VPS with 2 GB of RAM is a perfectly good Postgres server for a lot of products, as long as you stop copying tuning advice written for 64 GB machines.

What mattered in the end, in order: shared_buffers at 25% of RAM, not 40–50%; a connection pooler in front, because 100 idle connections cost more than they look; and random_page_cost near 1.1 on NVMe, which finally made the planner use the indexes it had been ignoring.

work_mem is the parameter that gets people into trouble. It is per sort node, per connection. Setting it to 64 MB on a box with 2 GB and a pool of 20 is a plan for the OOM killer to visit during the one query that matters.

The benchmark I trust is boring: pgbench at the concurrency you actually serve, run before and after, same data, same machine, three times. One number I don't trust is a single run on an empty database — empty tables make every setting look fine.

The other honest measurement: pg_stat_statements after a week of real traffic. Almost every "Postgres is slow" ticket I've seen was one query executed ten thousand times, not a missing parameter.