How much CPU and RAM does PostgreSQL need on a dedicated vCPU VPS?

How many vCPU does PostgreSQL use?

PostgreSQL uses one CPU thread per running query, because every connection gets its own backend process. The documentation calls it a "process per user" model: the postmaster spawns a new backend for each connection. The CPU a database needs is therefore set by the number of queries executing at the same instant, not by the number of open connections. An idle connection costs memory and no CPU.

Three things add threads on top of your queries:

• Parallel query. A large scan recruits helpers: max_parallel_workers_per_gather defaults to 2 and max_parallel_workers to 8, drawn from max_worker_processes (default 8).
• Autovacuum. Up to autovacuum_max_workers processes (default 3) clean tables in the background.
• The application, when it runs on the same VPS.

On a 2-vCPU VPS, one report that goes parallel can occupy every thread while the app's short queries wait behind it. Lowering max_parallel_workers_per_gather for the reporting role, or moving up a plan, solves it. The thread-versus-core rule behind these counts is explained in is a dedicated vCPU a core or a thread.

How much RAM does PostgreSQL need on a VPS?

Start shared_buffers at 25% of the VPS's RAM and leave most of the rest to the operating system's page cache. The PostgreSQL 18 documentation gives that starting value for a dedicated database server with 1 GB or more of RAM, and adds that more than 40% is unlikely to work better, because PostgreSQL also relies on the kernel's cache. The shipped default is 128 MB.

Two more settings follow from the RAM:

• effective_cache_size is an estimate for the planner only (default 4 GB). Set it to what shared_buffers and the page cache hold together, so index scans are costed correctly.
• work_mem (default 4 MB) applies to each sort or hash step in each session. One complex query uses it several times over, and many sessions do so at once, so it grows with care.

According to Cobaltfell's survey of 2 November 2026, 106 of the 202 dedicated-CPU plans recorded at hosts that take crypto without an ID check gave 4 GB of RAM or more per vCPU. For a database, RAM per vCPU matters as much as the vCPU count.

The plans behind that count are listed in what a dedicated CPU VPS costs per core in November 2026.

How does CPU steal affect PostgreSQL p99 latency?

CPU steal stretches the slowest 1% of queries long before it moves the average. The Linux kernel describes steal as involuntary wait: time when a vCPU had work while the hypervisor ran someone else. A backend paused mid-query simply stops, and every client waiting on that query, or on a lock it holds, stops with it.

The pauses are short and irregular, so they hit only the queries that happen to be on the CPU at that moment. As an illustration, not a measurement: when a vCPU loses a few tens of milliseconds to a neighbour now and then, a 2 ms query that lands in one of those windows takes ten times longer, while the thousands of queries around it run at normal speed. The mean barely changes; the 99th percentile carries the whole cost.

A database on a shared vCPU therefore looks healthy in averages and still produces timeouts. Three readings expose it:

• Steal: the %steal column of mpstat during the busiest hour, explained in what CPU steal time is and how to check it on a VPS.
• Worst cases: pg_stat_statements reports max_exec_time and stddev_exec_time per statement, and no percentiles.
• Percentiles: log_min_duration_statement (for example 250ms) logs slow statements; a latency histogram in the application gives the p99 itself.

# queries on the CPU right now (run at your busiest hour)
psql -c "SELECT count(*) FROM pg_stat_activity WHERE state = 'active';"

# statements with the worst single run (needs pg_stat_statements in shared_preload_libraries)
psql -c "SELECT left(query, 60) AS query, calls,
  round(mean_exec_time::numeric, 2) AS mean_ms,
  round(max_exec_time::numeric, 2) AS max_ms
  FROM pg_stat_statements ORDER BY max_exec_time DESC LIMIT 10;"

# steal per vCPU, every 5 seconds (package sysstat)
mpstat -P ALL 5 6

What does a dedicated vCPU change for a database?

A dedicated vCPU removes the one source of tail latency that cannot be tuned from inside the VPS. Slow plans, missing indexes and lock contention are the operator's to fix; a neighbour's batch job on a shared core is not. The general case is laid out in what is the difference between a shared and a dedicated vCPU. On a Cobaltfell VPS:

• CPU: A vCPU is one hardware thread of the host processor. Yours are pinned one to one to your VPS and never lent to another customer, and the two threads of a physical core stay together, so every 2 vCPU make one whole core that no neighbour shares.
• Steal: On a dedicated vCPU, steal time should sit at or near zero. We will publish the figure we measure on our own machines, with its date, and never an estimate.
• Memory: The RAM of your plan is set aside for your VPS and is not overcommitted.
• Disk: NVMe storage on every plan.
• Load: Full load is allowed for as long as your work needs it: no CPU credits, no burst window and no throttling after some minutes at 100%. A long VACUUM or index build runs flat out.

The processor family is AMD EPYC 9004/9005 (Zen 4 / Zen 5).

When is a VPS the wrong home for PostgreSQL?

A VPS is the wrong home when the data queried every minute is much larger than the RAM of the largest plan, or when replicas and backups must be managed for you. Fell 16 has 32 GB. A working set that does not fit in memory turns every query into disk reads, and storage throughput, not vCPU, then sets the pace.

Backups stay with the operator: Backups are not part of any plan: keep a copy of your data somewhere else. A nightly pg_dump or a WAL archive sent to storage in another place covers most small databases; a restore test belongs on the calendar before it is needed.

Failover across two or three VPS with streaming replication works, but it is self-managed. Cobaltfell sells the servers, not a managed database. Prices for each size are listed under how much a dedicated-core VPS costs.