Warum PostgreSQL-Replikation auf einem VPS 2026 unverzichtbar ist
Die Anforderungen an Datenbankverfügbarkeit sind 2026 höher denn je. Studien zeigen, dass eine einzige Stunde Datenbankausfall kleine Unternehmen durchschnittlich 8.500 bis 25.000 Euro kostet, während E-Commerce-Plattformen sogar bis zu 100.000 Euro pro Stunde verlieren können. Eine Master-Slave-Replikation auf zwei getrennten VPS-Servern reduziert das Risiko eines Single Point of Failure drastisch und schafft gleichzeitig die Grundlage für Read-Scaling.
Im Vergleich zu Cloud-Datenbankdiensten wie AWS RDS oder Google Cloud SQL sparen Sie mit einer eigenen PostgreSQL-Replikation auf VPS-Servern zwischen 40 % und 70 % der monatlichen Kosten. Bei einem typischen Setup mit 200 GB Speicher und 4 vCPUs zahlen Sie für verwaltete Lösungen rund 180–350 Euro pro Monat, während Sie mit zwei Hetzner- oder Netcup-VPS nur 35–60 Euro investieren.
Die PostgreSQL-Replikation basiert auf dem Write-Ahead Log (WAL), das jede Änderung am Master aufzeichnet und an einen oder mehrere Slaves überträgt. Asynchrone Replikation bietet die beste Performance, während synchrone Replikation absolute Datenkonsistenz garantiert – allerdings mit einer Latenz von etwa 2–8 ms zusätzlich pro Commit.
| Replikationstyp | Latenz | Datenverlust-Risiko | Empfohlene Nutzung |
|---|---|---|---|
| Asynchron (Standard) | 50–500 ms | Bis zu 60 Sekunden | Read-Scaling, Reporting |
| Synchron | +2–8 ms/Commit | Kein Datenverlust | Finanzdaten, kritische Apps |
| Kaskadiert | Variabel | Stufenweise | Globale Verteilung |
| Logisch (pglogical) | 100–800 ms | Konfigurierbar | Selektive Replikation |
Hardware-Anforderungen und VPS-Auswahl 2026
Für eine produktive Master-Slave-Konfiguration benötigen beide VPS-Server identische oder zumindest ähnliche Ressourcen. Empfohlen werden mindestens 4 vCPUs, 8 GB RAM und 160 GB NVMe-Speicher für eine Datenbank bis 50 GB. Der Slave kann etwas schwächer dimensioniert werden, da er primär Leseoperationen verarbeitet.
Die RAM-Größe entscheidet maßgeblich über die Performance: PostgreSQL nutzt shared_buffers für Datenzugriffe und effective_cache_size für Query-Planung. Als Faustregel gilt: 25 % des RAM für shared_buffers und 75 % für effective_cache_size. Bei 8 GB RAM ergibt das 2 GB bzw. 6 GB.
NVMe-SSDs sind 2026 Standard und bieten mit 500.000 IOPS etwa zehnmal mehr Leistung als herkömmliche SATA-SSDs. Die Netzwerkanbindung sollte mindestens 1 Gbit/s betragen, besser 2,5 Gbit/s, da die WAL-Files kontinuierlich zwischen den Servern übertragen werden müssen.
- Master-VPS: 4 vCPUs, 8 GB RAM, 200 GB NVMe, 1 Gbit/s – ab 18 Euro/Monat
- Slave-VPS: 4 vCPUs, 8 GB RAM, 200 GB NVMe, 1 Gbit/s – ab 18 Euro/Monat
- Standort: Gleicher DC-Standort für Latenz < 2 ms
- Betriebssystem: Ubuntu 24.04 LTS oder Debian 12 (Bookworm)
Vorbereitung: VPS bereitstellen und SSH absichern
Bestellen Sie zwei VPS-Server beim gleichen Anbieter im gleichen Rechenzentrum. Hetzner (Falkenstein/Nürnberg), Netcup (Wien/Nürnberg) und IONOS (Karlsruhe) bieten 2026 dedizierte PostgreSQL-VPS-Tarife zwischen 12 und 25 Euro pro Monat an. Achten Sie auf eine öffentliche IPv4-Adresse sowie eine private Netzwerkschnittstelle für den internen Datenverkehr.
Nach der Bereitstellung aktualisieren Sie zunächst das System und installieren die Grundpakete. Verwenden Sie niemals das root-Konto für den Datenbankbetrieb, sondern legen Sie einen separaten Benutzer an. Erstellen Sie außerdem SSH-Keys mit ed25519-Algorithmus, da diese 2026 als Standard gelten und 40 % sicherer als RSA-2048 sind.
# System aktualisieren
sudo apt update && sudo apt upgrade -y
# Grundlegende Pakete installieren
sudo apt install -y curl wget gnupg2 lsb-release ca-certificates
# SSH-Key generieren (auf lokalem Rechner)
ssh-keygen -t ed25519 -C "postgres-replica-2026"
# Public Key auf beide Server kopieren
ssh-copy-id -i ~/.ssh/id_ed25519.pub admin@MASTER_IP
ssh-copy-id -i ~/.ssh/id_ed25519.pub admin@SLAVE_IP
Konfigurieren Sie die SSH-Daemon-Konfiguration, um den root-Login zu deaktivieren und ausschließlich Public-Key-Authentifizierung zuzulassen. Bearbeiten Sie /etc/ssh/sshd_config und setzen Sie PermitRootLogin no sowie PasswordAuthentication no. Starten Sie den Dienst anschließend mit sudo systemctl restart sshd neu.
Konfigurieren Sie die interne Kommunikation über das private Netzwerk mit fester IP-Konfiguration. Bearbeiten Sie /etc/netplan/01-netcfg.yaml auf Ubuntu und weisen Sie dem Master die private IP 10.0.1.10 und dem Slave 10.0.1.20 zu. Dies reduziert die Latenz auf unter 1 ms und spart Traffic-Kosten, da Anbieter internen Datenverkehr oft nicht berechnen.
PostgreSQL 18 auf beiden Servern installieren
PostgreSQL 18 wurde im September 2025 veröffentlicht und bringt erhebliche Performance-Verbesserungen mit: bis zu 35 % schnellere Bulk-Inserts und optimiertes Vacuum. Fügen Sie zunächst das offizielle PostgreSQL-Repository hinzu, da Ubuntu 24.04 nur Version 16 enthält.
# PostgreSQL Repository hinzufügen
sudo sh -c 'echo "deb https://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'
# GPG-Key importieren
curl -fsSL https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/postgresql.gpg
# Installation durchführen
sudo apt update
sudo apt install -y postgresql-18 postgresql-client-18
Überprüfen Sie die Installation mit psql --version. Die Ausgabe sollte psql (PostgreSQL) 18.0 oder höher zeigen. Standardmäßig legt Debian/Ubuntu einen postgres-Systemuser an, der für die Verwaltung genutzt wird.
Stoppen Sie nach der Installation den PostgreSQL-Dienst auf beiden Servern, da die Konfiguration für die Replikation angepasst werden muss. Verwenden Sie sudo systemctl stop postgresql und prüfen Sie den Status mit sudo systemctl status postgresql.
Master-Server konfigurieren
Die Master-Konfiguration erfordert Änderungen an der postgresql.conf und der pg_hba.conf. Diese Dateien befinden sich 2026 unter /etc/postgresql/18/main/. Erstellen Sie vor jeder Änderung ein Backup der Originalkonfiguration mit sudo cp postgresql.conf postgresql.conf.bak.
# /etc/postgresql/18/main/postgresql.conf
listen_addresses = '10.0.1.10,MASTER_PUBLIC_IP'
wal_level = replica
max_wal_senders = 10
wal_keep_size = '2GB'
max_replication_slots = 10
hot_standby = on
archive_mode = on
archive_command = 'cp %p /var/lib/postgresql/18/main/archive/%f'
synchronous_commit = on
Der Parameter wal_level = replica aktiviert die Replikationsinformationen im Write-Ahead Log. max_wal_senders definiert die maximale Anzahl gleichzeitiger Slave-Verbindungen, wal_keep_size legt fest, wie viele WAL-Dateien vorgehalten werden, bevor alte gelöscht werden. Bei 2 GB Speicherplatz können Sie etwa 12–18 Stunden Netzwerkausfall überbrücken.
Erstellen Sie das Archiv-Verzeichnis und weisen Sie dem postgres-User die nötigen Rechte zu. Anschließend bearbeiten Sie pg_hba.conf, um dem Slave die Replikationsverbindungen zu erlauben. Verwenden Sie für die Authentifizierung scram-sha-256, das 2026 als Standard gilt und MD5 vollständig abgelöst hat.
# /etc/postgresql/18/main/pg_hba.conf
host replication replicator 10.0.1.20/32 scram-sha-256
host all app_user 10.0.1.20/32 scram-sha-256
Erstellen Sie einen dedizierten Replikations-User und ein Passwort mit CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD 'SicheresPasswort2026!';. Notieren Sie sich das Passwort sicher, da es für die Slave-Konfiguration benötigt wird. Starten Sie den PostgreSQL-Dienst neu mit sudo systemctl restart postgresql.
Slave-Server konfigurieren und initialisieren
Der Slave-Server benötigt zunächst eine Kopie des Master-Datenverzeichnisses. Stoppen Sie PostgreSQL auf dem Slave und löschen Sie das bestehende Datenverzeichnis. Verwenden Sie pg_basebackup, um eine konsistente Momentaufnahme zu erstellen – dieser Prozess dauert bei 50 GB etwa 8–15 Minuten.
# PostgreSQL auf Slave stoppen
sudo systemctl stop postgresql
# Datenverzeichnis leeren
sudo rm -rf /var/lib/postgresql/18/main/*
# Backup vom Master ziehen
sudo -u postgres pg_basebackup -h 10.0.1.10 \
-D /var/lib/postgresql/18/main \
-U replicator -P -Xs -R
# Rechte korrigieren
sudo chown -R postgres:postgres /var/lib/postgresql/18/main
Das Argument -R erstellt automatisch die standby.signal-Datei und eine postgresql.auto.conf mit den Verbindungsdaten. Überprüfen Sie die erstellte Konfiguration mit cat /var/lib/postgresql/18/main/postgresql.auto.conf und passen Sie bei Bedarf den Port, das Passwort und die IP-Adresse an.
# Automatisch generierte postgresql.auto.conf
primary_conninfo = 'host=10.0.1.10 port=5432 user=replicator password=SicheresPasswort2026! application_name=slave01'
primary_slot_name = 'replica_slot_01'
Erstellen Sie zusätzlich einen Replikations-Slot auf dem Master, damit WAL-Dateien nicht vorzeitig gelöscht werden. Verbinden Sie sich mit psql -h MASTER_IP -U postgres und führen Sie SELECT * FROM pg_create_physical_replication_slot('replica_slot_01'); aus. Dieser Slot garantiert Datenkonsistenz auch bei temporären Netzwerkunterbrechungen.
Starten Sie den PostgreSQL-Dienst auf dem Slave und überwachen Sie die Log-Datei /var/log/postgresql/postgresql-18-main.log. Eine erfolgreiche Replikation erkennen Sie an der Meldung started streaming WAL from primary innerhalb der ersten 30 Sekunden nach dem Start.
Replikation verifizieren und Monitoring einrichten
Überprüfen Sie den Replikationsstatus auf dem Master mit folgender SQL-Abfrage. Die Spalte state sollte streaming anzeigen und sent_lsn sollte kontinuierlich wachsen:
SELECT pid, state, sent_lsn, replay_lsn,
(sent_lsn - replay_lsn) AS lag_bytes,
write_lag, flush_lag, replay_lag
FROM pg_stat_replication;
Ein Lag von 0 bis 50 MB gilt als normal, bei 100–500 MB sollten Sie die Netzwerkbandbreite prüfen. Werte über 1 GB deuten auf einen Engpass hin und erfordern eine Anpassung von wal_compression = on und max_wal_size = '4GB'. Auf dem Slave können Sie mit SELECT pg_last_wal_receive_lsn(); den letzten empfangenen WAL-Pointer abfragen.
Installieren Sie pgwatch2 oder Prometheus mit postgres_exporter für professionelles Monitoring. Der postgres_exporter bietet über 120 Metriken und lässt sich in Grafana visualisieren. Konfigurieren Sie Alerts bei einem Lag von mehr als 500 MB oder wenn der Slave länger als 60 Sekunden disconnected ist.
| Monitoring-Tool | Setup-Aufwand | Funktionsumfang | Lizenzkosten |
|---|---|---|---|
| pgwatch2 | 2 Stunden | Sehr hoch | Kostenlos (AGPL) |
| Prometheus + postgres_exporter | 3 Stunden | Hoch | Kostenlos |
| pgAdmin 4 | 30 Minuten | Mittel | Kostenlos (PostgreSQL) |
| Datadog / New Relic | 1 Stunde | Sehr hoch | 15–35 Euro/Host/Monat |
Failover und automatisches Switching einrichten
Im Fehlerfall muss der Slave manuell oder automatisch zum neuen Master werden. Mit Patroni und etcd lässt sich automatisches Failover in unter 30 Sekunden realisieren. Patroni ist ein Open-Source-Tool von Zalando, das 2026 in über 12.000 Produktivumgebungen eingesetzt wird.
# Patroni Installation
sudo apt install -y python3-pip
sudo pip3 install patroni[etcd] psycopg2-binary
# /etc/patroni.yml
scope: postgres-cluster
namespace: /db/
name: node1
restapi:
listen: 0.0.0.0:8008
connect_address: 10.0.1.10:8008
etcd:
host: 10.0.1.5:2379
bootstrap:
dcs:
ttl: 30
loop_wait: 10
retry_timeout: 10
maximum_lag_on_failover: 1048576
postgresql:
use_pg_rewind: true
parameters:
wal_level: replica
Patroni überwacht kontinuierlich den Master und initiiert bei Ausfall einen automatischen Switchover. Die typische Failover-Zeit liegt bei 10–25 Sekunden, inklusive DNS-Update und Anwendungsumschaltung. Für 99,99 % Verfügbarkeit (maximal 52 Minuten Ausfall pro Jahr) benötigen Sie zusätzlich ein Load-Balancer-Setup mit HAProxy oder ProxySQL.
Testen Sie das Failover regelmäßig in einer Staging-Umgebung. Hetzner und Netcup bieten hierfür günstige Test-VPS ab 4 Euro pro Monat an. Ein Failover-Test pro Quartal wird in den Best Practices der PostgreSQL Community empfohlen und deckt 95 % aller Szenarien ab.
Performance-Tuning für Replikations-Workloads
Die Replikation verursacht zusätzliche I/O-Last auf beiden Servern. Aktivieren Sie wal_compression = on, um die zu übertragende Datenmenge um 60–80 % zu reduzieren. Diese Einstellung kostet etwa 5 % CPU-Leistung auf dem Master, spart aber erheblich Netzwerkbandbreite ein.
Konfigurieren Sie checkpoint_completion_target = 0.9 und max_wal_size = '4GB', um die Schreiblast gleichmäßiger zu verteilen. Erhöhen Sie wal_buffers = '64MB' auf Servern mit viel RAM. Diese drei Parameter zusammen können die Schreibperformance um 20–40 % steigern.
# Optimierte postgresql.conf für Master + Replikation
wal_compression = on
wal_buffers = '64MB'
max_wal_size = '4GB'
min_wal_size = '1GB'
checkpoint_completion_target = 0.9
random_page_cost = 1.1
effective_io_concurrency = 200
default_statistics_target = 500
Für den Slave-Server, der primär Lesequeries verarbeitet, empfiehlt sich eine Anpassung von effective_cache_size auf 75 % des RAM und work_mem = '32MB' pro Connection. Bei 100 gleichzeitigen Connections ergibt das einen maximalen Work-Mem-Verbrauch von 3,2 GB. Aktivieren Sie außerdem hot_standby_feedback = on, um Konflikte zwischen langen Lesequeries und Replikation zu reduzieren.
Sicherheit, Backups und Kosten im Vergleich
Verschlüsseln Sie die Replikationsverbindungen mit SSL/TLS. PostgreSQL 18 unterstützt TLS 1.3 nativ, was die CPU-Last um 15 % senkt im Vergleich zu TLS 1.2. Generieren Sie Zertifikate mit Let's Encrypt oder einer internen CA, und erzwingen Sie ssl = on in der postgresql.conf.
Ergänzend zur Replikation benötigen Sie regelmäßige Backups. pgBackRest ist 2026 das bevorzugte Tool für inkrementelle Backups und unterstützt parallele Komprimierung. Eine vollständige Sicherung von 100 GB dauert mit pgBackRest etwa 8 Minuten, die Wiederherstellung 12 Minuten. Speichern Sie Backups auf einem externen Object-Storage wie Hetzner Storage Box (ab 3,50 Euro/Monat) oder Backblaze B2.
| Anbieter | VPS-Preis (4 vCPU/8 GB) | DC-Standort | Netzwerk | Support |
|---|---|---|---|---|
| Hetzner Cloud | 18,90 €/Monat | Falkenstein, Nürnberg | 20 TB inklusive | 24/7, deutschsprachig |
| Netcup | 15,99 €/Monat | Wien, Nürnberg | Unbegrenzt | Werktags |
| IONOS | 20,00 €/Monat | Karlsruhe, Frankfurt | Unbegrenzt | 24/7, deutschsprachig |
| Strato | 17,99 €/Monat | Berlin, Frankfurt | Unbegrenzt | 24/7 |
| Contabo | 13,99 €/Monat | Nürnberg, Düsseldorf | 32 TB | 24/7, englisch |
Die monatlichen Gesamtkosten für ein vollständiges Master-Slave-Setup belaufen sich 2026 auf 35–55 Euro inklusive Backups. Gegenüber einer vergleichbaren AWS-RDS-Multi-AZ-Konfiguration (ab 350 Euro/Monat) sparen Sie über 80 %, müssen allerdings auch Wartung, Monitoring und Sicherheit selbst verantworten.
Fazit und Best Practices für 2026
Eine PostgreSQL-Master-Slave-Replikation auf zwei VPS-Servern ist 2026 die kosteneffizienteste Lösung für Verfügbarkeit und Read-Scaling. Mit einem Investitionsvolumen von 40–60 Euro pro Monat erhalten Sie eine professionelle Architektur, die 99,95 % Verfügbarkeit erreicht und Reads linear skaliert.
Die wichtigsten Erfolgsfaktoren sind: identische Hardware auf beiden Servern, gleicher DC-Standort für minimale Latenz, dedizierte Replikations-User mit scram-sha-256-Authentifizierung, Replikations-Slots zur Vermeidung von WAL-Verlust sowie regelmäßige Failover-Tests. Setzen Sie auf PostgreSQL 18, Patroni für automatisches Failover und Prometheus für Monitoring.
Planen Sie für 2026 mindestens 8 Stunden Wartungsaufwand pro Monat ein, inklusive Updates, Monitoring-Review und Backup-Tests. Bei wachsenden Anforderungen können Sie später eine dritte Stufe mit einem Cascading-Replica oder logischer Replikation zwischen verschiedenen Datenbankversionen hinzufügen. So bleibt Ihre Architektur flexibel und zukunftssicher.