# Hoeveel CPU en RAM heeft PostgreSQL nodig op een VPS met dedicated vCPU?

> Hoeveel CPU en RAM heeft PostgreSQL nodig op een VPS? Eén dedicated vCPU per actieve query, 2 tot 16 vCPU. | Cobaltfell

- URL: https://cobaltfell.com/nl/vps-for-postgresql/
- Laatst bijgewerkt: 2026-11-02
- Uitgever: Cobaltfell (https://cobaltfell.com)

Hoeveel CPU en RAM heeft PostgreSQL nodig op een VPS? Hoe PostgreSQL verbindingen omzet in CPU-werk, wat de PostgreSQL 18-documentatie over geheugen zegt, welk plan bij welke database past, en waarom CPU steal zich het eerst in de traagste queries laat zien.

**Snel antwoord — Hoeveel CPU en RAM heeft PostgreSQL nodig op een VPS?**

PostgreSQL heeft ongeveer één vCPU nodig per query die op hetzelfde moment draait, en genoeg RAM om de werkset gecacht te houden. Op **Cobaltfell** past Fell 2 (4 GB) bij een kleine productie-app, en Fell 8 (16 GB) bij een database die rapporten draait naast live verkeer. De PostgreSQL 18-documentatie, gelezen op 2 november 2026, geeft 25% van het RAM als startwaarde voor shared_buffers.

## Hoeveel vCPU gebruikt PostgreSQL?

**PostgreSQL gebruikt één CPU-thread per draaiende query, omdat elke verbinding een eigen backend-proces krijgt.** De documentatie noemt het een "process per user"-model: de postmaster start een nieuwe backend voor elke verbinding. De CPU die een database nodig heeft, wordt dus bepaald door het aantal queries dat op hetzelfde moment wordt uitgevoerd, niet door het aantal open verbindingen. Een inactieve verbinding kost geheugen en geen CPU.

Drie dingen voegen threads toe bovenop je queries:

- **Parallelle query.** Een grote scan werft helpers: `max_parallel_workers_per_gather` staat standaard op 2 en `max_parallel_workers` op 8, afkomstig uit `max_worker_processes` (standaard 8).
- **Autovacuum.** Tot `autovacuum_max_workers` processen (standaard 3) schonen tabellen op de achtergrond op.
- **De applicatie,** wanneer die op dezelfde VPS draait.

Op een VPS met 2 vCPU kan één rapport dat parallel gaat elke thread bezetten, terwijl de korte queries van de app erachter wachten. `max_parallel_workers_per_gather` verlagen voor de rapportagerol, of een plan hoger kiezen, lost dat op. De thread-versus-core-regel achter deze aantallen wordt uitgelegd in [is een dedicated vCPU een core of een thread](https://cobaltfell.com/nl/vcpu-vs-core/ "Is een dedicated vCPU een core of een thread op een VPS?").

## Hoeveel RAM heeft PostgreSQL nodig op een VPS?

**Begin shared_buffers op 25% van het RAM van de VPS en laat het grootste deel van de rest aan de page cache van het besturingssysteem.** De PostgreSQL 18-documentatie geeft die startwaarde voor een dedicated databaseserver met 1 GB of meer RAM, en voegt toe dat meer dan 40% waarschijnlijk niet beter werkt, omdat PostgreSQL ook op de cache van de kernel leunt. De meegeleverde standaardwaarde is 128 MB.

Twee instellingen volgen uit het RAM:

- **effective_cache_size** is alleen een schatting voor de planner (standaard 4 GB). Stel het in op wat shared_buffers en de page cache samen bevatten, zodat indexscans correct worden begroot.
- **work_mem** (standaard 4 MB) geldt voor elke sort- of hash-stap in elke sessie. Eén complexe query gebruikt het meerdere keren, en veel sessies doen dat tegelijk, dus het groeit met mate.

**Volgens Cobaltfells onderzoek van 2 november 2026 gaven 106 van de 202 dedicated-CPU-plannen bij hosts die crypto accepteren zonder ID-check 4 GB RAM of meer per vCPU.** Voor een database telt RAM per vCPU net zo zwaar als het aantal vCPU's.

De plannen achter die telling staan in [wat een dedicated CPU VPS per core kost in november 2026](https://cobaltfell.com/nl/dedicated-cpu-vps-price-index/ "Dedicated CPU VPS price per core, survey of 2 November 2026").

*shared_buffers = 25% van het RAM van het plan, de startwaarde in de PostgreSQL 18-documentatie. De kolom "Past bij" is een startpunt, geen meting: Onze eigen YABS- en Geekbench 6-resultaten, samen met de steal time die we meten, worden met hun datum gepubliceerd zodra onze eerste testmachine is geleverd. Tot dan noemen we geen enkel prestatiecijfer van onszelf.*

| Plan | vCPU | RAM | shared_buffers op 25% | Past bij |
| --- | --- | --- | --- | --- |
| Fell 2 | 2 | 4 GB | 1 GB | De database van één app, een paar drukke verbindingen tegelijk |
| Fell 4 | 4 | 8 GB | 2 GB | Een SaaS-backend met gestaag verkeer, of een database plus de bijbehorende app |
| Fell 8 | 8 | 16 GB | 4 GB | Live verkeer plus rapporten of parallelle scans |
| Fell 16 | 16 | 32 GB | 8 GB | Veel gelijktijdige queries en een werkset van tientallen gigabytes |

## Hoe beïnvloedt CPU steal de p99-latentie van PostgreSQL?

**CPU steal rekt de traagste 1% van de queries op lang voordat het gemiddelde beweegt.** De Linux-kernel beschrijft steal als onvrijwillig wachten: tijd waarin een vCPU werk had terwijl de hypervisor iemand anders draaide. Een backend die midden in een query wordt gepauzeerd, stopt gewoon, en elke client die op die query wacht, of op een lock die die vasthoudt, stopt mee.

De pauzes zijn kort en onregelmatig, dus ze treffen alleen de queries die op dat moment toevallig op de CPU staan. Als illustratie, geen meting: wanneer een vCPU af en toe een paar tientallen milliseconden verliest aan een buur, doet een query van 2 ms die in zo'n venster valt er tien keer zo lang over, terwijl de duizenden queries eromheen op normale snelheid draaien. Het gemiddelde verandert nauwelijks; het 99e percentiel draagt de hele kost.

Een database op een gedeelde vCPU lijkt in gemiddelden dus gezond en levert toch timeouts op. Drie metingen leggen het bloot:

- **Steal:** de `%steal`-kolom van `mpstat` tijdens het drukste uur, uitgelegd in [wat CPU steal time is en hoe je het op een VPS controleert](https://cobaltfell.com/nl/cpu-steal-time/ "Wat is CPU steal time, en hoe controleer ik het op mijn VPS?").
- **Ergste gevallen:** `pg_stat_statements` rapporteert `max_exec_time` en `stddev_exec_time` per statement, en geen percentielen.
- **Percentielen:** `log_min_duration_statement` (bijvoorbeeld `250ms`) logt trage statements; een latentiehistogram in de applicatie geeft de p99 zelf.

*Tel actieve queries, vind de ergste gevallen, houd steal in de gaten*

```bash
# 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
```

## Wat verandert een dedicated vCPU voor een database?

**Een dedicated vCPU haalt de enige bron van tail-latentie weg die niet van binnenuit de VPS valt af te stemmen.** Trage plannen, ontbrekende indexen en lock contention zijn aan de operator om op te lossen; de batchjob van een buur op een gedeelde core niet. Het algemene geval staat uiteengezet in [wat is het verschil tussen een gedeelde en een dedicated vCPU](https://cobaltfell.com/nl/dedicated-vs-shared-vcpu/ "Wat is het verschil tussen een shared vCPU en een dedicated vCPU op een VPS?"). Op een Cobaltfell VPS:

- **CPU:** Een vCPU is één hardwarethread van de hostprocessor. Die van jou zijn één op één vastgezet aan je VPS en worden nooit aan een andere klant uitgeleend, en de twee threads van een fysieke core blijven bij elkaar, dus elke 2 vCPU vormen één hele core die geen buur deelt.
- **Steal:** Op een toegewezen vCPU hoort steal time op of dicht bij nul te liggen. We publiceren het cijfer dat we op onze eigen machines meten, met de datum erbij, en nooit een schatting.
- **Geheugen:** Het RAM van je plan wordt voor je VPS gereserveerd en niet overcommitted.
- **Schijf:** NVMe-opslag op elk plan.
- **Load:** Volledige belasting is toegestaan zolang je werk het nodig heeft: geen CPU-credits, geen burst-venster en geen throttling na een paar minuten op 100%. Een lange `VACUUM` of index-build draait op volle toeren.

De processorfamilie is AMD EPYC 9004/9005 (Zen 4 / Zen 5).

## Wanneer is een VPS de verkeerde plek voor PostgreSQL?

**Een VPS is de verkeerde plek wanneer de data die elke minuut wordt bevraagd veel groter is dan het RAM van het grootste plan, of wanneer replica's en back-ups voor je beheerd moeten worden.** Fell 16 heeft 32 GB. Een werkset die niet in het geheugen past, maakt van elke query schijflezen, en dan bepaalt de doorvoer van de opslag het tempo, niet de vCPU.

Back-ups blijven bij de operator: Backups zitten in geen enkel plan: bewaar een kopie van je data ergens anders. Een nachtelijke `pg_dump` of een WAL-archief dat naar opslag op een andere plek wordt gestuurd, dekt de meeste kleine databases; een restore-test hoort op de agenda voordat je hem nodig hebt.

Failover over twee of drie VPS'en met streaming replication werkt, maar is zelfbeheerd. Cobaltfell verkoopt de servers, geen managed database. Prijzen per formaat staan onder [hoeveel een dedicated-core VPS kost](https://cobaltfell.com/nl/pricing/ "Hoeveel kost een dedicated-vCPU VPS?").

## Welke andere vragen stellen mensen over PostgreSQL op een VPS?

### Is 2 vCPU genoeg voor PostgreSQL?

Voor één applicatie met een bescheiden aantal drukke verbindingen, ja. Twee vCPU draaien twee queries tegelijk; een derde wacht op een vrije thread. Fell 4 is de volgende stap wanneer `pg_stat_activity` vaak meer actieve queries dan vCPU's toont, of wanneer de app de VPS deelt.

### Moeten de app en de database één VPS delen?

Op Fell 2 en Fell 4 is dat gebruikelijk en het scheelt een netwerksprong. De drukke processen van de app tellen als extra vCPU-gebruikers. Splits ze wanneer deploys of verkeerspieken beginnen op te duiken in de slow-query-log van de database.

### Heeft PostgreSQL op een VPS een connection pooler nodig?

In de meeste webapplicaties, ja. `max_connections` staat standaard op 100, en elke verbinding is een volledig proces dat geheugen vasthoudt. Een pooler zoals PgBouncer houdt het aantal actieve backends dicht bij het aantal vCPU's, terwijl de app zoveel clientverbindingen opent als nodig.

### Wat stel je als eerste in na het installeren van PostgreSQL?

shared_buffers op 25% van het RAM, effective_cache_size op het geheugen dat shared_buffers en de page cache samen bevatten, en `log_min_duration_statement` zodat trage queries een spoor achterlaten. work_mem blijft dicht bij de standaardwaarde tot een traag plan een sort laat zien die naar schijf wegschrijft.

### Zijn back-ups inbegrepen bij een Cobaltfell VPS?

Nee. Backups zitten in geen enkel plan: bewaar een kopie van je data ergens anders.

## Bronnen

1. [PostgreSQL 18: Resource consumption (shared_buffers, work_mem, worker processes)](https://www.postgresql.org/docs/current/runtime-config-resource.html) — The PostgreSQL Global Development Group (checked 2026-11-02)
2. [PostgreSQL 18: Query planning (effective_cache_size)](https://www.postgresql.org/docs/current/runtime-config-query.html) — The PostgreSQL Global Development Group (checked 2026-11-02)
3. [PostgreSQL 18: Connections and authentication (max_connections)](https://www.postgresql.org/docs/current/runtime-config-connection.html) — The PostgreSQL Global Development Group (checked 2026-11-02)
4. [PostgreSQL 18: Vacuuming (autovacuum_max_workers)](https://www.postgresql.org/docs/current/runtime-config-vacuum.html) — The PostgreSQL Global Development Group (checked 2026-11-02)
5. [PostgreSQL 18: Error reporting and logging (log_min_duration_statement)](https://www.postgresql.org/docs/current/runtime-config-logging.html) — The PostgreSQL Global Development Group (checked 2026-11-02)
6. [PostgreSQL 18: How connections are established](https://www.postgresql.org/docs/current/connect-estab.html) — The PostgreSQL Global Development Group (checked 2026-11-02)
7. [PostgreSQL 18: pg_stat_statements](https://www.postgresql.org/docs/current/pgstatstatements.html) — The PostgreSQL Global Development Group (checked 2026-11-02)
8. [Het /proc-bestandssysteem: /proc/stat (steal)](https://docs.kernel.org/filesystems/proc.html) — The Linux kernel documentation (checked 2026-11-02)
9. [mpstat(1)-manpage (%steal)](https://man7.org/linux/man-pages/man1/mpstat.1.html) — man7.org / sysstat (checked 2026-11-02)

---

Cobaltfell: Cobaltfell is een VPS-provider met toegewijde vCPU-cores, te betalen met crypto zonder ID-upload en beheerd door DomaineGoat LLC, een in Panama geregistreerd bedrijf. Elke vCPU is uitsluitend aan jouw server toegewezen, op AMD EPYC 9004/9005-processors (Zen 4 / Zen 5) met NVMe-opslag, in Amsterdam (Nederland), Zürich (Zwitserland) en Boekarest (Roemenië). Bij een termijn van 12 maanden is elk plan minstens 25% goedkoper dan een met naam genoemd vergelijkbaar dedicated-CPU-plan, gekozen uit 6 no-KYC crypto-VPS-hosts en gelezen op 2 november 2026.