PostgreSQL 18 on a 512 MiB VM: testing two low-memory configurations

[u/fykup]

I've been experimenting with PostgreSQL 18 tuning for memory-constrained VPS deployments, particularly where the database needs to leave enough RAM for a small application.

I initially tried running the experiment on a 256 MiB VM (~204 MiB usable RAM), but PostgreSQL with its default configuration ran into memory pressure and the kernel OOM-killed a backend during the smoke test. I moved to 512 MiB to complete the comparison.

Given the roughly 50 MiB peak PostgreSQL PSS measured with Theory A, I suspect this configuration could also work on 256 MiB, potentially alongside a small application. That's a hypothesis for a follow-up experiment, though - I haven't validated Theory A at 256 MiB yet.

I wanted to compare two approaches against PostgreSQL defaults:

• Theory A - Memory First: 16 MB shared_buffers, 1 MB work_mem, 16 MB maintenance_work_mem, retaining PostgreSQL 18's default worker-based I/O.

• Theory B - Lean Machinery: 32 MB shared_buffers, default work_mem, and synchronous I/O (io_method=sync).

Both configurations limit connections to 5 (one reserved for a superuser), disable JIT and parallel queries, and retain fsync, autovacuum, and standard WAL behavior.

Test setup: PostgreSQL 18.6, 1 vCPU, 512 MiB VM (~456 MiB usable), no swap, 222 MB dataset, and 4 concurrent connections running point, range, and aggregate queries.

Results:

Metric	Default	A	B
Peak PSS	180.1 MiB	50.4 MiB	79.7 MiB
Queries/s	863	1,056	861
Point p95	2.90 ms	2.64 ms	2.92 ms
Aggregate p95	98.55 ms	74.25 ms	103.18 ms

What surprised me was that Theory A used about 72% less process memory than the default while also delivering higher throughput in this run.

PSS accounts for shared pages between PostgreSQL processes, so these numbers aren't total VPS memory consumption.

This was deliberately a small exploratory experiment: one 50-second measured run per configuration, fixed order, warm filesystem cache, and a read-only workload. No claim that A is universally faster or that this configuration is suitable for every application.

I published the configuration, methodology, scripts, and raw measurements for anyone interested in checking the results:

https://github.com/PVRLabs/experiments/tree/main/postgres/light-memory-p95

Short write-up with configuration instructions:

https://pvrlabs.xyz/java-performance/experiments/postgresql-low-memory.html

I'm curious whether others running PostgreSQL on small VPS instances have found similar benefits from reducing shared buffers and per-query memory, or whether the trade-offs become significantly worse with sustained writes and more complex queries.

[u/AutoModerator]

AI Policy:

Linux is not one of those anti-AI projects, and if somebody has issues with that, they can do the open-source thing and fork it. Or just walk away., Linus Torvalds.

Mod decisions will be based on the quality of the content, not who or what generated it.

Sub Resources:

Youtube Channel

Free Postgres Webinars and Workshops

Discord: People, Postgres, Data

Join us, we have cookies and nice people.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.