Wie viel CPU und RAM braucht PostgreSQL auf einem VPS mit dedizierten vCPU?

Wie viele vCPU nutzt PostgreSQL?

PostgreSQL nutzt einen CPU-Thread pro laufender Abfrage, denn jede Verbindung erhält einen eigenen Backend-Prozess. Die Dokumentation nennt das ein „Prozess pro Benutzer“-Modell: Der Postmaster startet für jede Verbindung ein neues Backend. Der CPU-Bedarf einer Datenbank richtet sich daher nach der Anzahl der gleichzeitig ausgeführten Abfragen, nicht nach der Anzahl der offenen Verbindungen. Eine untätige Verbindung kostet Speicher und keine CPU.

Drei Dinge kommen zu Ihren Abfragen als zusätzliche Threads hinzu:

• Parallele Abfrage. Ein großer Scan zieht Helfer heran: max_parallel_workers_per_gather hat den Standardwert 2 und max_parallel_workers den Standardwert 8, entnommen aus max_worker_processes (Standard 8).
• Autovacuum. Bis zu autovacuum_max_workers Prozesse (Standard 3) bereinigen Tabellen im Hintergrund.
• Die Anwendung, wenn sie auf demselben VPS läuft.

Auf einem 2-vCPU-VPS kann ein Bericht, der parallel läuft, jeden Thread belegen, während die kurzen Abfragen der Anwendung dahinter warten. max_parallel_workers_per_gather für die Reporting-Rolle zu senken oder einen Tarif höher zu gehen, löst das. Die Regel Thread versus Kern hinter diesen Zahlen wird erklärt in ist eine dedizierte vCPU ein Kern oder ein Thread.

Wie viel RAM benötigt PostgreSQL auf einem VPS?

Starten Sie shared_buffers bei 25 % des RAM des VPS und überlassen Sie den Großteil des Rests dem Page Cache des Betriebssystems. Die PostgreSQL-18-Dokumentation nennt diesen Ausgangswert für einen dedizierten Datenbankserver mit 1 GB oder mehr RAM und ergänzt, dass mehr als 40 % wahrscheinlich nicht besser funktionieren, weil PostgreSQL auch auf den Cache des Kernels angewiesen ist. Der mitgelieferte Standardwert ist 128 MB.

Zwei weitere Einstellungen ergeben sich aus dem RAM:

• effective_cache_size ist nur eine Schätzung für den Planer (Standard 4 GB). Setzen Sie ihn auf den Speicher, den shared_buffers und der Page Cache zusammen halten, damit Index-Scans korrekt bewertet werden.
• work_mem (Standard 4 MB) gilt für jeden Sortier- oder Hash-Schritt in jeder Sitzung. Eine komplexe Abfrage nutzt ihn mehrfach, und viele Sitzungen tun dies gleichzeitig, also wächst er mit Bedacht.

Laut der Erhebung von Cobaltfell vom 2. November 2026 lieferten 106 der 202 Tarife mit dedizierter CPU, die bei Hosts erfasst wurden, die Krypto ohne Identitätsprüfung akzeptieren, 4 GB RAM oder mehr pro vCPU. Für eine Datenbank zählt RAM pro vCPU genauso viel wie die Anzahl der vCPU.

Die Tarife hinter dieser Zahl sind aufgeführt in was ein dedizierter CPU-VPS im November 2026 pro Kern kostet.

Wie wirkt sich CPU-Steal auf die PostgreSQL-p99-Latenz aus?

CPU-Steal dehnt die langsamsten 1 % der Abfragen lange bevor er den Durchschnitt bewegt. Der Linux-Kernel beschreibt Steal als unfreiwilliges Warten: Zeit, in der eine vCPU Arbeit hatte, während der Hypervisor jemand anderen laufen ließ. Ein Backend, das mitten in einer Abfrage pausiert wird, stoppt einfach, und jeder Client, der auf diese Abfrage wartet oder auf eine von ihr gehaltene Sperre, stoppt mit.

Die Pausen sind kurz und unregelmäßig, daher treffen sie nur die Abfragen, die in diesem Moment gerade auf der CPU liegen. Als Veranschaulichung, nicht als Messung: Wenn eine vCPU hier und da einige Dutzend Millisekunden an einen Nachbarn verliert, braucht eine 2-ms-Abfrage, die in eines dieser Fenster fällt, zehnmal so lange, während die Tausenden Abfragen drumherum mit normaler Geschwindigkeit laufen. Der Mittelwert ändert sich kaum; das 99. Perzentil trägt die gesamten Kosten.

Eine Datenbank auf einer geteilten vCPU wirkt daher in Durchschnittswerten gesund und erzeugt trotzdem Timeouts. Drei Messwerte legen es offen:

• Steal: die Spalte %steal von mpstat während der verkehrsreichsten Stunde, erklärt in was CPU-Steal-Zeit ist und wie man sie auf einem VPS prüft.
• Worst Cases: pg_stat_statements meldet max_exec_time und stddev_exec_time pro Statement, aber keine Perzentile.
• Perzentile: log_min_duration_statement (zum Beispiel 250ms) protokolliert langsame Statements; ein Latenz-Histogramm in der Anwendung liefert das p99 selbst.

# 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

Was ändert eine dedizierte vCPU für eine Datenbank?

Eine dedizierte vCPU beseitigt die eine Quelle von Tail-Latenz, die sich von innerhalb des VPS nicht beheben lässt. Langsame Pläne, fehlende Indizes und Lock-Contention liegen in der Hand des Betreibers; der Batch-Job eines Nachbarn auf einem geteilten Kern nicht. Der allgemeine Fall ist dargestellt in was der Unterschied zwischen einer geteilten und einer dedizierten vCPU ist. Auf einem Cobaltfell-VPS:

• CPU: Eine vCPU ist ein Hardware-Thread des Host-Prozessors. Ihre vCPUs sind eins zu eins an Ihren VPS gebunden und werden nie an einen anderen Kunden verliehen, und die beiden Threads eines physischen Kerns bleiben zusammen, sodass je 2 vCPU einen ganzen Kern ergeben, den kein Nachbar teilt.
• Steal: Bei einer dedizierten vCPU sollte die Steal Time bei oder nahe null liegen. Wir veröffentlichen den Wert, den wir auf unseren eigenen Maschinen messen, mit Datum, und niemals eine Schätzung.
• Arbeitsspeicher: Der Arbeitsspeicher Ihres Plans ist für Ihren VPS reserviert und nicht überbucht.
• Festplatte: NVMe-Speicher in jedem Plan.
• Load: Volllast ist erlaubt, solange Ihre Arbeit sie benötigt: keine CPU-Credits, kein Burst-Fenster und kein Drosseln nach einigen Minuten bei 100 %. Ein langer VACUUM oder Index-Build läuft mit voller Leistung.

Die Prozessorfamilie ist AMD EPYC 9004/9005 (Zen 4 / Zen 5).

Wann ist ein VPS der falsche Ort für PostgreSQL?

Ein VPS ist der falsche Ort, wenn die jede Minute abgefragten Daten deutlich größer sind als der RAM des größten Tarifs oder wenn Replikate und Backups für Sie verwaltet werden müssen. Fell 16 hat 32 GB. Ein Arbeitsspeicherbedarf (Working Set), der nicht in den Speicher passt, macht jede Abfrage zu Festplattenlesevorgängen, und dann gibt der Speicherdurchsatz, nicht die vCPU, das Tempo vor.

Backups bleiben beim Betreiber: Backups sind in keinem Plan enthalten: Bewahren Sie eine Kopie Ihrer Daten woanders auf. Ein nächtliches pg_dump oder ein WAL-Archiv, das an einen anderen Ort im Speicher gesendet wird, deckt die meisten kleinen Datenbanken ab; ein Wiederherstellungstest gehört in den Kalender, bevor man ihn braucht.

Failover über zwei oder drei VPS mit Streaming-Replikation funktioniert, ist aber selbstverwaltet. Cobaltfell verkauft die Server, keine verwaltete Datenbank. Preise für jede Größe sind aufgeführt unter wie viel ein VPS mit dediziertem Kern kostet.