PostgreSQL auf einem VPS: Arbeitsspeicher und Festplatte bemessen

Vom genutzten Volumen ausgehen

Der Arbeitsspeicher eines Datenbankservers dient zuerst als Cache: eine aus dem Speicher gelesene Seite wird weit schneller ausgeliefert als eine von der Festplatte gelesene, selbst von NVMe. Die Frage ist also nicht nur „Wie groß ist die Datenbank?“, sondern „Welcher Teil wird häufig gelesen?“. Eine Datenbank von 50 GB, von der nur die letzten zwölf Monate abgefragt werden, arbeitet vielleicht mit 8 GB.

Bei einer bestehenden Datenbank liefern zwei Abfragen das Gesamtvolumen und die größten Tabellen, Indizes inklusive:

SELECT pg_size_pretty(pg_database_size(current_database()));

SELECT relname AS tabelle,
       pg_size_pretty(pg_total_relation_size(relid)) AS groesse_mit_indizes
FROM pg_catalog.pg_statio_user_tables
ORDER BY pg_total_relation_size(relid) DESC
LIMIT 10;

Für eine künftige Datenbank schätzen Sie Tabelle für Tabelle: erwartete Zeilen nach einem Jahr × durchschnittliche Zeilengröße, dann kommen die Indizes hinzu, die üblicherweise 30 bis 100 % der Daten wiegen. Beispiel: 2 Millionen Zeilen pro Monat zu je 500 Byte ergeben 12 GB Daten nach einem Jahr und 18 bis 24 GB mit den Indizes.

Der Arbeitsspeicher: die Starteinstellungen

PostgreSQL hält gelesene Seiten auf zwei Ebenen: in seinem eigenen Cache (shared_buffers) und im Datei-Cache des Systems. Seine Dokumentation empfiehlt, auf einem dedizierten Server mit 25 % des Arbeitsspeichers für shared_buffers zu beginnen, und stellt fest, dass über 40 % hinaus der Gewinn selten wird: der Rest kommt dem Cache des Systems und den Sortiervorgängen zugute.

Diese Werte setzen eine Datenbank allein auf dem Server voraus. Läuft die Anwendung daneben, ziehen Sie zuerst ihren Speicherbedarf ab (Prozesse, Cache, Build) und wenden die Prozentsätze auf den Rest an: ein Server mit 8 GB, der eine Anwendung mit 3 GB betreibt, wird eingestellt wie ein Datenbankserver mit 5 GB.

shared_buffers = 2GB
effective_cache_size = 6GB
work_mem = 16MB
maintenance_work_mem = 512MB
random_page_cost = 1.1

shared_buffers wird erst beim Neustart von PostgreSQL wirksam; die übrigen Parameter werden ohne Unterbrechung neu geladen, per SELECT pg_reload_conf();.

Ob der Arbeitsspeicher reicht, zeigt die Cache-Trefferquote. Bei einer Geschäftsanwendung oder einer Website liegt sie über 99 %:

SELECT round(100.0 * blks_hit / nullif(blks_hit + blks_read, 0), 2) AS cache_trefferquote
FROM pg_stat_database
WHERE datname = current_database();

Die Verbindungen: je ein Prozess

PostgreSQL öffnet einen Prozess pro Verbindung und akzeptiert standardmäßig 100 (max_connections). Jeder Prozess belegt im Leerlauf einige Megabyte, mehr, wenn er Daten sortiert oder hasht (work_mem, manchmal mehrfach in einer einzigen Abfrage). max_connections auf 500 anzuheben, um mit einer gesprächigen Anwendung Schritt zu halten, setzt den Server der Gefahr aus, bei der ersten Spitze keinen Arbeitsspeicher mehr zu haben.

Die richtige Antwort ist ein Connection Pooler: PgBouncer im Modus transaction lässt Hunderte Verbindungen der Anwendung einige Dutzend echte Verbindungen teilen. Auch die Frameworks haben ihren eigenen Pool (SQLAlchemy, Prisma, HikariCP): richten Sie seine Größe nach der Zahl der vCPU des Datenbankservers aus statt nach der Zahl der Nutzer.

Die Festplatte: Volumen, Reserve und Transaktionslog

Die Festplatte eines PostgreSQL-Servers trägt mehr als die Tabellen:

• Die Daten und die Indizes und ihr Wachstum über ein Jahr.
• Das Transaktionslog (WAL): standardmäßig 1 GB zwischen zwei Checkpoints (max_wal_size), mehr während eines Massenimports und noch mehr, wenn die Archivierung des Logs in Rückstand gerät.
• Die temporären Dateien von Sortiervorgängen, die work_mem überschreiten.
• Der Platz für eine Reorganisation: VACUUM FULL und der Neuaufbau eines Index schreiben eine vollständige Kopie, bevor sie die alte freigeben.
• Die lokalen Exporte, wenn Sie Backups auf dem Server aufbewahren, bevor Sie sie anderswohin senden.

Die Regel: das Volumen in einem Jahr, plus mindestens 30 % Reserve. Das ist kein Komfort: füllt sich die Festplatte, die das Transaktionslog trägt, hält PostgreSQL an, um seine Daten zu schützen. Überwachen Sie die Belegung und erweitern Sie vor 80 %.

Bei der Leistung zählt vor allem das Schreiben. Jeder Commit wartet, bis das Transaktionslog auf der Festplatte steht, also bestimmt die Latenz des Speichers den Schreibdurchsatz. Hier macht eine NVMe-SSD den Unterschied, weit mehr als beim Lesen, das der Arbeitsspeicher schon bedient.

Der Prozessor: eine Abfrage, ein Kern

Eine PostgreSQL-Abfrage läuft auf einem einzigen Kern, außer bei großen Lesevorgängen, die die Datenbank parallelisiert. Die Zahl der vCPU bestimmt also, wie viele schwere Abfragen gleichzeitig laufen: 2 vCPU genügen einer Geschäftsanwendung zum Start, 4 bis 8 passen für stark beanspruchte Datenbanken und aufwendige Berichte.

Bevor Sie vCPU hinzufügen, suchen Sie die Abfragen, die sie verbrauchen. Die Erweiterung pg_stat_statements sortiert sie nach Gesamtzeit:

shared_preload_libraries = 'pg_stat_statements'

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

SELECT calls, round(total_exec_time) AS ms_gesamt,
       round(mean_exec_time::numeric, 1) AS ms_mittel, query
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 10;

Derselbe Server wie die Anwendung oder ein eigener?

Zum Start ist die Datenbank auf demselben Server wie die Anwendung die richtige Wahl: keine Netzwerklatenz zwischen beiden, eine Verbindung über einen Unix-Socket, ein einziger Server, den es zu sichern und zu überwachen gilt. Getrennt wird, wenn beide um die Ressourcen konkurrieren: ein Build oder eine Traffic-Spitze, die den Cache der Datenbank leert, eine Datenbank, die den gesamten Arbeitsspeicher für ihre Daten braucht, oder unterschiedliche Anforderungen an die Backups.

Sicherheit und Backups

• Nur lokal erreichbar: listen_addresses = 'localhost', solange sich nur die Anwendung auf dem Server verbindet. Muss ein anderer Server zugreifen, öffnen Sie Port 5432 nur für seine Adresse, in der Firewall und in pg_hba.conf.
• Authentifizierung: Methode scram-sha-256 in pg_hba.conf, eine Rolle pro Anwendung, ohne Superuser-Rechte.
• Logisches Backup täglich per pg_dump, außerhalb des Servers kopiert.
• Wiederherstellung auf einen bestimmten Zeitpunkt: die kontinuierliche Archivierung des Transaktionslogs (pgBackRest, WAL-G) erlaubt es, auf die Minute genau vor einen Fehler zurückzugehen, wo ein täglicher Export zum Vortag zurückführt.
• Getestete Wiederherstellung: ein Backup beweist sich, indem man es wiederherstellt, in einer Testdatenbank, in regelmäßigen Abständen.

pg_dump -Fc -d meine_db -f meine_db-$(date +%F).dump
createdb meine_db_test
pg_restore -d meine_db_test meine_db-2026-10-29.dump