Selbstgehostetes PostgreSQL auf einem VPS: Schluss mit den Preisen für verwaltete Datenbanken

Rechenleistung. Speicher. Backup-Aufbewahrung.

Der Snapshot-Export, den du vergessen hast. Die Egress-Gebühr aus der Staging-Umgebung, die letzten Dienstag ein „pg_dump“ ausgeführt hat.

Niemand öffnet die Rechnung für seine verwaltete Datenbank und erwartet, dass sie günstig ist.

Aber puh.

Die Lücke zwischen Postgres für 25 $ im Monat und dem, was am Ende auf der Kreditkartenabrechnung steht, ist groß geworden. Ein 4-GB-VPS zum Preis eines einzigen Supabase-Add-ons betreibt heute deine komplette Datenbank und lässt dem Betriebssystem noch genug Platz, um häufig genutzte Seiten zu cachen.

Eine produktive Postgres-Datenbank selbst zu hosten ist längst nicht mehr der betriebliche Albtraum von früher. Das Repo der PostgreSQL Global Development Group (PGDG) ist ausgereift; moderne PostgreSQL-Installationen (v14+) verwenden standardmäßig SCRAM-SHA-256 zur Passwortverschlüsselung, und das veraltete MD5 ist seit v18 offiziell als deprecated markiert. Die Gründe, warum Leute heute bei RDS, Supabase oder Neon bleiben, sind betrieblicher Natur, nicht technischer.

Wir sprechen über echte Rechnungen, echten Betriebsaufwand und darüber, wie modernes Postgres-Hosting wirklich aussieht.

Was kostet es wirklich, PostgreSQL auf einem VPS selbst zu hosten?

Ein selbstgehostetes PostgreSQL auf einem 4-GB-VPS kostet meist nur einen Bruchteil vergleichbarer Tarife von RDS, Supabase Pro oder Neon Scale, sobald Speicher, Backups und Egress in der verwalteten Rechnung dazukommen.

PostgreSQL ist die Datenbank, die 55,6 % der Entwickler nutzen – laut dem Developer Survey 2025 von Stack Overflow – und damit seit zwei Jahren in Folge die beliebteste. Außerdem ist es eine Datenbank, die du problemlos selbst betreiben kannst.

Vergleich für einen typischen Workload eines kleinen Teams (4 GB RAM, ~100 GB Daten, geringe bis mittlere Schreiblast, eine Region), Preise Stand Mai 2026:

Der On-Demand-Preis für RDS db.t4g.medium liegt bei etwa 0,065 $ pro Stunde, also rund 47,45 $ im Monat allein für die Rechenleistung.

Kommen 100 GB gp3-Speicher zu etwa 0,115 $/GB-Monat und automatische Backups dazu, landet eine Single-AZ-Instanz bei rund 60 $/Monat. Schaltest du Multi-AZ-Failover ein, verdoppelt sich der Posten für Rechenleistung ungefähr, und eine produktionsreife Konfiguration kostet 100 $/Monat und mehr.

Das ist keine kleine Lücke.

Selbst hosten ist günstiger, weil du die Arbeit übernimmst, die du bei der verwalteten Lösung mitbezahlt hast: Betriebsdisziplin, Bereitschaftsdienst, um 2 Uhr nachts, wenn die Festplatte vollläuft. Die verwaltete Datenbank, mit der du vergleichst, kann im nächsten Quartal eine andere Preisuntergrenze haben – rechne also mit deiner eigenen Rechnung nach, bevor du dich festlegst.

Wann lohnt es sich, PostgreSQL selbst zu hosten?

Ein selbstgehostetes PostgreSQL auf einem VPS lohnt sich, wenn dein Team grundlegend mit Linux umgehen kann, der Workload gleichmäßig ist, die Größe des Working Sets vorhersehbar ist und du einen echten Grund hast, der verwalteten Rechnung zu entkommen.

Es funktioniert nicht, wenn du keine Kapazität für den Betrieb hast, regulatorische HA-Anforderungen erfüllen musst, die du nicht selbst umsetzen kannst, oder dein Lastmuster so sprunghaft ist, dass du von sofortiger Skalierung profitierst.

Drei Dinge bestimmen diese Entscheidung: Kosten, Datenschutz und Datensouveränität sowie Kontrolle.

Wo selbstgehostet klar gewinnt:

• Gleichmäßiger Traffic in einer einzigen Region mit vorhersehbarem Working Set.
• Kleine bis mittlere SaaS-Apps mit einer Postgres-Datenbank und einem Team, das mit Linux vertraut ist.
• Datenschutzsensible Workloads, bei denen die Datenbank nicht in der Umgebung eines anderen Anbieters liegen sollte.
• Kostenbewusste Teams, deren verwaltete Rechnung inzwischen höher ist als der Aufwand für den eigenen Betrieb.

Wo verwaltet klar gewinnt:

• Sprunghafte Workloads, die von sofortigem Hoch- und Herunterskalieren profitieren.
• Multi-Region-Setups, bei denen globale Replikation das eigentliche Produkt ist.
• Regulierte Umgebungen, die schlüsselfertige HA, Compliance-Zertifikate und Audit-Trails brauchen.
• Teams ohne freie Betriebskapazität und ohne Plan, sie aufzubauen.

Die Zahl von 40 % bis 60 % Kostenersparnis wird oft zitiert. Achte genau darauf, wie alt sie ist.

Im Jahr 2021 dokumentierte AWS-Autor Rupesh Desai, dass PostgreSQL auf EC2 bei gleichwertigen Spezifikationen 40 % bis 60 % günstiger lief als RDS – das ist älter als die meisten aktuellen RDS-Instanzfamilien.

Die aktuelle Version ist die Kostenanalyse von byteiota, veröffentlicht Ende 2025, laut der RDS 75 % bis 88 % teurer ist als vergleichbare dedizierte Hardware.

Der ehrliche Break-even-Punkt hängt an den Betriebsstunden, nicht an den Serverkosten.

Wie wählst du die richtige VPS-Größe für PostgreSQL?

Die meisten produktiven Anwendungsdatenbanken laufen problemlos mit 4 GB RAM und NVMe-Speicher. Größere Datenmengen, viele parallele Verbindungen oder Analytics-Workloads erhöhen den Bedarf auf 8 GB, 16 GB und mehr.

Der RAM bestimmt, wie viel deines Working Sets Postgres im Arbeitsspeicher halten kann; sobald häufig genutzte Seiten auf die Festplatte ausgelagert werden, werden Abfragen langsamer. NVMe ist wichtig, weil Postgres empfindlich auf die Latenz zufälliger Lesezugriffe bei häufig genutzten Seiten und auf den Schreibdurchsatz für das Write-Ahead-Log reagiert.

Gängige Empfehlungen zum PostgreSQL-Tuning beginnen mit:

• shared_buffers auf etwa 25 % des System-RAM.
• effective_cache_size auf etwa 50–75 % des System-RAM.
• work_mem konservativ bemessen – ausgehend von der Komplexität paralleler Abfragen, nicht allein vom gesamten RAM.

Auf einem 4-GB-VPS heißt das in der Regel, etwa 1 GB für shared_buffers zu reservieren und gleichzeitig genug Speicher für den Linux-Page-Cache zu lassen, damit häufig genutzte Daten dort bleiben. Diese Balance ist ein Grund dafür, dass eine bescheidene 4-GB-Maschine viele kleine bis mittelgroße Produktions-Workloads problemlos bewältigt.

Welcher Tarif zu welchem Workload passt:

Die VPS-Hosting-Tarife von DreamHost bieten dir Root-Zugriff, NVMe-Speicher und unbegrenzte Bandbreite – bei einer planbaren monatlichen Rechnung.

Genau von diesen vier Dingen hängt ein selbstgehosteter Postgres-Workload ab.

Wie installierst du PostgreSQL auf einem VPS?

Du installierst PostgreSQL auf einem VPS in fünf kompakten Schritten.

1. VPS bereitstellen: Wähle einen Tarif mit genug RAM für dein Working Set (Stack 8/8 GB für die Produktion). Ubuntu 24.04 LTS ist das empfohlene Betriebssystem. Melde dich per SSH mit Schlüssel-Authentifizierung an, nicht mit Passwort.
2. Aus dem offiziellen PGDG-Repo installieren: Das ‘apt install postgresql’ der Distribution hinkt bei den Hauptversionen hinterher. Füge das PGDG-apt-Repo hinzu und führe dann ‘sudo apt install postgresql-18.’ aus. Prüfe das Ergebnis mit ‘sudo systemctl status postgresql’
3. Passwort für postgres festlegen und App-Rolle anlegen: Führe sudo -i -u postgres aus, dann psql und anschließend password postgres. Lege eine eigene Rolle mit minimalen Rechten an: ‘CREATE ROLE myapp WITH LOGIN PASSWORD '...';’ und ‘CREATE DATABASE myapp_prod OWNER myapp;’
4. Listener richtig binden: Öffne /etc/postgresql/18/main/postgresql.conf. Setze listen_addresses = ‘localhost’, wenn App und Datenbank auf derselben Maschine laufen, oder binde an eine private IP, wenn die App auf einem separaten VPS läuft. Binde PostgreSQL nicht an 0.0.0.0 auf einer öffentlich erreichbaren Schnittstelle. Offen erreichbare PostgreSQL-Instanzen werden von automatisierten Bots aggressiv gescannt und per Brute Force angegriffen.
5. „pg_hba.conf“ und UFW absichern: Bearbeite pg_hba.conf so, dass nur die Anwendungs-IPs zugelassen sind, die du wirklich brauchst, mit „scram-sha-256“ als Authentifizierungsmethode. Konfiguriere UFW so, dass Port 5432 nur von genau diesen IPs erreichbar ist. Nutze für Admin-Tools einen SSH-Tunnel (und öffne Port 5432 bitte nicht für das öffentliche Internet).

Teste das von einem anderen Rechner aus: psql -h <vps-ip> -U postgres.

Ein Timeout oder eine abgelehnte Verbindung von einer nicht autorisierten IP bedeutet in der Regel, dass Listener und Firewall-Regeln ihren Job machen. Eine Passwortabfrage aus dem öffentlichen Internet bedeutet, dass etwas falsch konfiguriert ist. Sobald Postgres läuft, ist die Konfiguration erst die halbe Arbeit.

Wie sicherst du PostgreSQL auf einem VPS ab?

PostgreSQL auf einem VPS sicherst du auf drei Ebenen ab – dazu kommen saubere Rollenverwaltung und regelmäßige Updates.

1. Authentifizierung: Verwende scram-sha-256 für neue Installationen und entferne alte md5-Regeln aus pg_hba.conf. Die Dokumentation von PostgreSQL warnt inzwischen, dass die Unterstützung für MD5-verschlüsselte Passwörter deprecated ist und in einer künftigen Version entfernt wird.
2. Netzwerk: Binde PostgreSQL an „localhost“, eine private IP oder eine Schnittstelle, die nur deine Anwendungsserver erreichen. Vermeide es, an eine öffentlich erreichbare Schnittstelle zu binden. Setze UFW obendrauf und erlaube Port 5432 nur von vertrauenswürdigen Anwendungs-IPs.
3. Verschlüsselung bei der Übertragung: Aktiviere TLS für jede Verbindung, die eine Netzwerkgrenze überschreitet. Setze ssl = on in postgresql.conf und verwende dann hostssl … scram-sha-256-Regeln in pg_hba.conf, damit Clients nicht unbemerkt auf Verbindungen ohne TLS zurückfallen. Selbstsignierte Zertifikate sind für internen Traffic in Ordnung, sofern die Clients sie korrekt prüfen.
4. Rollen: Anwendungsverbindungen sollten eine Rolle mit minimalen Rechten nutzen, die nur die Berechtigungen für die Schemas dieser App hat. Der Superuser ist für Migrationen und Notfälle da.
5. Updates: Nutze das PGDG-apt-Repo für aktuelle PostgreSQL-Pakete. Aktiviere automatische Sicherheitsupdates für das Betriebssystem, plane PostgreSQL-Updates aber bewusst ein, damit ein überraschender Neustart nicht zu deinem Vorfall der Woche wird.

Deine Sicherheits-Checkliste:

• Nur scram-sha-256 verwenden; md5 deaktivieren.
• „listen_addresses“ an localhost oder eine private IP binden.
• UFW-Regeln erlauben Port 5432 nur von vertrauenswürdigen IPs.
• SSL/TLS für jede Verbindung über Netzwerkgrenzen hinweg aktiviert.
• Die App verbindet sich mit einer Rolle mit minimalen Rechten, niemals als „postgres“.
• Automatische Sicherheitsupdates aktiviert.
• Niemals irgendwo in „pg_hba.conf“ eine Zeile „host all all 0.0.0.0/0 md5“.

Der letzte Punkt ist die Warnung schlechthin.

Ein öffentlich erreichbarer Port 5432 mit schwachen Zugangsdaten ist ein bekanntes Ziel für Kryptominer und Brute-Force-Angriffe. Offen erreichbare PostgreSQL-Instanzen werden ununterbrochen von automatisierten Bots gescannt, die nach Standardkonten, geleakten Passwörtern oder zu freizügigen pg_hba.conf-Regeln suchen.

Öffentlich erreichbare Postgres-Instanzen mit schwacher Authentifizierung werden oft erschreckend schnell kompromittiert. Eine Datenbank, die ohne passende Netzwerkkontrollen, TLS und Rollentrennung direkt im Internet hängt, ist genau die Art Fehler, die in einem Vorfallsbericht endet. Und auch eine korrekt konfigurierte Datenbank ist nur einen Festplattenausfall vom Datenverlust entfernt.

Wie richtest du Backups und Replikation für PostgreSQL auf einem VPS ein?

Für PostgreSQL-Backups auf einem VPS gibt es drei Mechanismen – welchen du wählst, hängt davon ab, vor welchem Ausfall du dich schützen willst: logische Backups mit pg_dump für Portabilität, physische Backups mit pg_basebackup plus WAL-Archivierung für Point-in-Time-Recovery und Streaming-Replikation für Hochverfügbarkeit.

Logische Backups eignen sich für Migrationen, teilweise Wiederherstellungen und das Auffrischen von Entwicklungsumgebungen. Führe pg_dump –format=custom –file=mydb.dump mydb_prod über einen täglichen Cron Job aus. Das Custom-Format lässt sich gut komprimieren und unterstützt – genau wie das Directory-Format – die parallelen und selektiven Wiederherstellungsoptionen von pg_restore. Lade den Dump in einen S3-kompatiblen Objektspeicher außerhalb des VPS hoch.

Physische Backups eignen sich für vollständige Systemwiederherstellungen und Point-in-Time-Recovery. Mit pg_basebackup und kontinuierlicher Archivierung des Write-Ahead-Logs (WAL) kannst du jeden beliebigen Zeitpunkt zwischen dem letzten Basis-Backup und dem neuesten WAL-Segment wiederherstellen – die produktionsreife Option, wenn du Datenverlust nur im Bereich von Sekunden statt Stunden tolerieren kannst.

Streaming-Replikation ist die dritte Option. Ein Lesereplikat auf einem zweiten VPS dient als Hot Standby für leseintensive Workloads oder als schnelles Failover-Ziel. Diese Replikation kostet dich einen zweiten VPS, begrenzt deinen schlimmsten Ausfall aber auf wenige Minuten.

Teste die Wiederherstellung monatlich. Verwaltete Dienste haben all das bereits eingebaut, und genau diese Arbeit holst du dir zurück, wenn du beim Selbsthosten sparst. Wenn du schon bei einem verwalteten Anbieter bist, ist der Wechsel einfacher, als er aussieht.

Wie migrierst du von RDS, Supabase oder Neon auf einen VPS?

Der Umzug von einem verwalteten Postgres-Anbieter auf einen VPS gelingt in vier Schritten.

1. Ziel-VPS bereitstellen: Verwende exakt dieselbe Postgres-Hauptversion wie auf der Quelle. Installiere PostgreSQL auf dem neuen VPS anhand der Schritte oben und lege anschließend die Anwendungsrolle und die Datenbank an.
2. Dump aus der Quelle erstellen: Führe pg_dump –format=custom –no-owner –no-privileges –file=src.dump <source-connection-string> aus. Die Flags –no-owner und –no-privileges entfernen anbieterspezifische Rollenberechtigungen, die sich auf einem neuen Host selten sauber wiederherstellen lassen.
3. Auf dem Ziel wiederherstellen: Führe pg_restore –dbname=myapp_prod –jobs=4 –no-owner –no-privileges src.dump aus. Achte auf Warnungen zu Erweiterungen. RDS, Supabase und Neon aktivieren oft Erweiterungen, die es in Standard-Postgres möglicherweise nicht gibt. Installiere kompatible Erweiterungen vor der Wiederherstellung aus den PGDG-Paketen oder aus postgresql-contrib.
4. Verbindungsstring austauschen und prüfen: Richte zuerst eine Staging-Umgebung auf den neuen VPS aus, lass deine Testsuite laufen und prüfe dann repräsentative Produktionsabfragen und Anwendungsabläufe, bevor du den Verbindungsstring der Produktion umstellst. Bei Anwendungen mit wenigen Schreibzugriffen ist ein kurzes Wartungsfenster für die finale Umstellung oft einfacher als eine Replikation. Lass die Quelldatenbank noch einige Tage online und schreibgeschützt, damit du bei Bedarf zurückwechseln kannst.

Was ändert sich je nach Anbieter?

1. Von RDS: RDS-spezifische Rollen („rds_superuser“, „rdsadmin“) gibt es in Standard-Postgres nicht; –no-owner und –no-privileges erledigen das meiste davon. Einige von RDS verwaltete Erweiterungen musst du manuell installieren, und der ausgehende Datenverkehr aus AWS während des Dumps wird berechnet.
2. Von Supabase: Das Postgres dort ist echtes Postgres, aber die Auth-, Storage- und Edge-Schichten von Supabase lassen sich nicht migrieren. Dein Anwendungsschema schon. Ersetze diese Schichten vor der Umstellung durch selbstgehostete Alternativen.
3. Von Neon: Branching fällt nach der Migration weg; plane stattdessen Backups ein. Dump und Wiederherstellung sind unkompliziert, aber für gewohnte Abläufe wie sofortige Branches brauchst du einen Ersatz-Workflow.

Die Migration selbst dauert meist kürzer als die Auswahl des VPS-Tarifs. Realistisch liegt die Ausfallzeit bei kleinen Datenbanken im Minutenbereich, bei großen dauert sie wegen des WAL-Replays länger. Bei den meisten Installationen ist hier Schluss, aber es gibt ein Szenario, das dich noch einen Schritt weiter bringt …

Wann brauchst du PgBouncer und wann reicht Standard-Postgres?

Die meisten Apps auf einem VPS mit 4 GB brauchen anfangs keinen Connection-Pooler. Füge PgBouncer hinzu, wenn die gleichzeitigen Verbindungen etwa 100 überschreiten oder dein Anwendungsstack pro Anfrage eine neue Verbindung öffnet.

PostgreSQL-Verbindungen sind ressourcenintensiv, weil jede einzelne ein vollständiger Betriebssystemprozess ist. Mit 4 GB RAM willst du nicht, dass Hunderte inaktiver Verbindungen Speicher fressen. Der Pooler hält auf der einen Seite die teuren Postgres-Verbindungen und gibt auf der anderen Seite günstige, kurzlebige Verbindungen an deine App aus.

Zwei Pooling-Modi sind relevant:

• Session-Pooling: Jeder Client erhält für die Dauer der Sitzung eine Serververbindung. Sicher für jede App, ohne geänderte Semantik, aber mit geringerem Durchsatzgewinn.
• Transaction-Pooling: Jeder Client erhält eine Serververbindung für eine Transaktion. Großer Durchsatzgewinn. Du verlierst allerdings Funktionen, die auf dem Sitzungszustand beruhen (Prepared Statements, Advisory Locks, „LISTEN“/„NOTIFY“), sofern die App nicht darauf ausgelegt ist.

Die meisten kleinen SaaS-Apps mit einem ORM mit Connection-Pooling kommen ohne PgBouncer aus – bis sie es nicht mehr tun. Das Signal, dass du die Grenze überschritten hast, sind Fehler wie „FATAL: too many connections“ oder Speicherdruck durch inaktive Verbindungen.

Installiere ihn mit sudo apt install pgbouncer, konfiguriere /etc/pgbouncer/pgbouncer.ini mit deiner Datenbankliste und dem Pool-Modus und richte die App dann auf PgBouncer an Port 6432 aus.

Ja, du merkst es, wenn du ihn brauchst.

Die endgültige Entscheidung

Der Kostenunterschied ist groß genug, um es mit deiner eigenen Rechnung durchzurechnen. Aber die Einrichtung ist nicht der schwierige Teil.

Der schwierige Teil ist die Betriebsarbeit, für die du bisher mit der Rechnung für die verwaltete Datenbank bezahlt hast: Backups, Wiederherstellungstests, Patches und Monitoring.

So oder so: Atme tief durch, bevor du die nächste Rechnung öffnest.

Häufig gestellte Fragen zu PostgreSQL auf einem VPS