Selbstgehostetes PostgreSQL auf einem VPS: Vermeide verwaltete DB-Preise

Rechenleistung. Speicher. Backup-Aufbewahrung.

Der Snapshot-Export, den Du vergessen hast. Die Ausgangsgebühr aus der Testumgebung, die letzten Dienstag ein ‚pg_dump‘ durchgeführt hat.

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

Aber, verdammt.

Die Kluft zwischen „Postgres für 25 $ pro Monat“ und dem, was auf der Karte angezeigt wird, ist groß geworden, und ein 4 GB VPS zum Preis eines einzelnen Supabase-Add-ons betreibt jetzt deine gesamte Datenbank mit noch genügend Platz für das Betriebssystem, um häufig genutzte Seiten zu cachen.

Ein Produktions-Postgres-Datenbanksystem selbst zu hosten, ist nicht mehr der operationelle Albtraum, der es einst war. Das PostgreSQL Global Development Group (PGDG) Repository ist solide; moderne PostgreSQL-Installationen (v14+) verwenden standardmäßig die SCRAM-SHA-256-Passwortverschlüsselung, wobei die veraltete MD5-Verschlüsselung ab Version 18 offiziell als veraltet gilt. Die Gründe, warum Menschen heute bei RDS, Supabase oder Neon bleiben, sind operationeller, nicht technischer Natur.

Wir sprechen über tatsächliche Rechnungen, tatsächliche Betriebskosten und wie modernes Postgres-Hosting wirklich aussieht.

Wie Viel Kostet Es Eigentlich, PostgreSQL Auf Einem VPS Selbst Zu Hosten?

Ein selbst gehostetes PostgreSQL auf einem 4 GB VPS läuft häufig zu einem Bruchteil der entsprechenden RDS-, Supabase Pro- oder Neon Scale-Preise, sobald Speicher, Backups und Egress in die verwaltete Rechnung einbezogen werden.

PostgreSQL ist die Datenbank, die 55,6% der Entwickler nutzen, laut der Entwicklerumfrage 2025 von Stack Overflow, die seit zwei Jahren in Folge die beliebteste ist. Es ist auch die Datenbank, die Du bequem selbst betreiben kannst.

Vergleich für eine repräsentative Arbeitslast eines kleinen Teams (4 GB RAM, ~100 GB Daten, geringe bis moderate Schreiblast, einzelne Region), Stand Mai 2026:

Option	Rechenleistung	Speicher	Ausgang über das kostenlose Kontingent	Am besten für
Self-hosted auf einem 4 GB VPS	Fester Tarifpreis	Üblicherweise inbegriffen	Üblicherweise ungemessen oder mit hoher Kapazität	Beständige Arbeitslasten, kostensensible Teams, die mit Linux vertraut sind
AWS RDS db.t4g.medium	47,45 $/Monat nur Rechenleistung	~0,115 $/GB-Monat gp3	~0,09 $/GB Internet/außerhalb der Region	Teams, die verwaltete Backups, Failover und AWS-native Operationen wünschen
Supabase Pro	25 $/Monat Basis + Nutzung	0,125 $/GB Datenbankdisk über die inbegriffenen 8 GB hinaus	0,09 $/GB über 250 GB hinaus	Apps, die Postgres, Authentifizierung, Speicher und Echtzeit in einem Stack benötigen
Neon Scale	0,222 $ pro CU/Stunde	0,35 $ pro GB/Monat	Nutzungsbasiert	Spitzenlasten, vorschauintensive, verzweigungsintensive Entwicklungsabläufe

Der RDS db.t4g.medium On-Demand-Preis beträgt ungefähr 0,065 $ pro Stunde oder etwa 47,45 $ pro Monat nur für die Rechenleistung.

Füge 100 GB gp3-Speicher für etwa 0,115 $/GB-Monat und automatisierte Backups hinzu, und ein Single-AZ-Box liegt bei etwa 60 $/Monat. Aktiviere das Multi-AZ-Failover und die Rechenleistung verdoppelt sich ungefähr, was eine produktionsreife Konfiguration auf 100 $/Monat und mehr bringt.

Das ist keine kleine Lücke.

Self-hosting ist günstiger, weil Du die Arbeit übernimmst, für die sonst die verwaltete Rechnung bezahlt wurde. Ops-Disziplin, Bereitschaftsdienst, um 2 Uhr morgens, wenn die Festplatte voll ist. Die verwaltete-DB-Alternative, mit der Du vergleichst, könnte nächstes Quartal andere Grundkosten haben, also rechne sie gegen Deine eigene Rechnung, bevor Du Dich festlegst.

Wann Macht Es Sinn, PostgreSQL Selbst Zu Hosten?

Das Selbsthosting von PostgreSQL auf einem VPS ist sinnvoll, wenn Du grundlegende Linux-Kenntnisse im Team hast, eine gleichbleibende Arbeitslast, eine vorhersehbare Arbeitsmengengröße und einen echten Grund, die verwaltete Rechnung zu umgehen.

Es funktioniert nicht, wenn Du keine Betriebskapazität hast, geregelte HA-Anforderungen, die Du nicht selbst erstellen kannst, oder ein sprunghaftes Muster, das von sofortiger Skalierung profitiert.

Drei Dinge treiben diese Entscheidung voran. Kosten, Datenschutz und Datenhoheit sowie Kontrolle.

Wo Selbstgehostetes Klar Überzeugt:

• Stetiger Datenverkehr in einer einzelnen Region mit einem vorhersehbaren Arbeitsumfang.
• Kleine bis mittelgroße SaaS-Anwendungen mit einer Postgres-Datenbank und einem Team, das sich mit Linux auskennt.
• Datenschutzsensible Arbeitslasten, bei denen die Datenbank nicht in der Tenantschaft eines anderen liegen sollte.
• Kostensensible Teams, deren verwaltete Rechnung über die Schwelle des Betriebsaufwands hinausgewachsen ist.

Wo Verwaltetes Klar Gewinnt:

• Burstartige Arbeitslasten, die von sofortigem Hoch- und Herunterskalieren profitieren.
• Mehrregionale Einrichtungen, bei denen globale Replikation das Produkt ist.
• Regulierte Umgebungen, die schlüsselfertige HA, Compliance-Zertifikate und Prüfpfade benötigen.
• Teams ohne freie Betriebskapazität und ohne Plan, diese aufzubauen.

Die Zahl von 40% bis 60% Kosteneinsparungen wird oft zitiert. Datieren Sie sie sorgfältig.

Seit 2021 hat AWS-Autor Rupesh Desai dokumentiert, dass PostgreSQL auf EC2 40% bis 60% günstiger als RDS bei entsprechenden Spezifikationen läuft, älter als die meisten aktuellen RDS-Instanzfamilien.

Die aktuelle Version ist die Kostenstapelanalyse von byteiota, veröffentlicht Ende 2025, die besagt, dass RDS 75% bis 88% teurer ist als entsprechende dedizierte Hardware.

Der ehrliche Break-Even sind die Betriebsstunden, nicht die Serverkosten.

Wie Wählst Du Die Richtige VPS-Größe Für PostgreSQL Aus?

Die meisten Produktionsanwendungsdatenbanken laufen problemlos auf 4 GB RAM mit NVMe-Speicher. Größere Datensätze, viele gleichzeitige Verbindungen oder Analyse-Workloads erhöhen den Bedarf auf 8 GB oder 16 GB und darüber.

RAM bestimmt, wie viel von deinem Arbeitsset Postgres im Speicher halten kann; sobald heiße Seiten auf die Festplatte ausgelagert werden, verlangsamen sich die Abfragen. NVMe ist wichtig, da Postgres empfindlich auf Zufallslese-Latenz für heiße Seiten und auf Durchsatz beim Leeren des vorausschauenden Protokolls reagiert.

Häufige PostgreSQL-Tuning-Empfehlungen beginnen mit:

• shared_buffers etwa 25% des System-RAM.
• effective_cache_size bei etwa 50%-75% des System-RAM.
• work_mem konservativ dimensioniert — basierend auf der Komplexität gleichzeitiger Abfragen, nicht nur auf dem Gesamt-RAM.

Auf einem 4 GB VPS bedeutet das normalerweise, etwa 1 GB für shared_buffers zu reservieren, während genug Speicher für den Linux-Seitencache übrig bleibt, um häufig genutzte Daten zu speichern. Diese Balance ist ein Grund, warum eine bescheidene 4 GB Box viele kleine bis mittelgroße Produktionslasten problemlos bewältigen kann.

Die Plan-Zu-Lasten-Karte, die Du kennen musst:

RAM-Stufe	Typische Arbeitslast	Empfohlener Stapelplan
2 GB	Entwicklungsumgebungen, wenig frequentierte Nebenprojekte	Unterhalb der Basislinie
4 GB	Die meisten Produktionsanwendungsdatenbanken	Stapel 4
8 GB	Größere Datensätze, mehr gleichzeitige Verbindungen	Stapel 8
16 GB+	Postgres neben anderen anspruchsvollen Diensten, Analysen	Stapel 16

DreamHosts VPS-Hosting-Pläne bieten Dir Root-Zugriff, NVMe-Speicher und unbegrenzte Bandbreite bei einer vorhersehbaren monatlichen Rechnung.

Das sind die vier Dinge, auf die eine selbstgehostete Postgres-Workload angewiesen ist.

Wie Installierst Du PostgreSQL Auf Einem VPS?

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

1. Richte Den VPS Ein: Wähle einen Tarif mit genügend RAM für Dein Arbeitsset (Stack 4/4 GB ist die Basis). Ubuntu 24.04 LTS ist das empfohlene Betriebssystem. Verbinde Dich über eine SSH-Schlüsselauthentifizierung und nicht über ein Passwort.
2. Installation Aus Dem Offiziellen PGDG-Repo: Die Distro ‘apt install postgresql’ hinkt in großen Versionen hinterher. Füge das PGDG-apt-Repo hinzu, dann ‘sudo apt install postgresql-18.’ Bestätige mit ‘sudo systemctl status postgresql’
3. Setze Das Postgres-Passwort Und Erstelle Deine App-Rolle: Führe sudo -i -u postgres, dann psql, dann password postgres aus. Erstelle eine dedizierte Rolle mit minimalen Rechten: ‘CREATE ROLE myapp WITH LOGIN PASSWORD '...';’ und ‘CREATE DATABASE myapp_prod OWNER myapp;’
4. Binde Den Listener Korrekt: Öffne /etc/postgresql/18/main/postgresql.conf. Setze listen_addresses = ‚localhost‘, wenn die App und die Datenbank auf demselben Server laufen, oder binde an eine private IP, wenn die App auf einem separaten VPS läuft. Vermeide es, PostgreSQL auf 0.0.0.0 an einer öffentlich erreichbaren Schnittstelle zu binden. Offengelegte PostgreSQL-Instanzen werden aggressiv gescannt und durch automatisierte Bots brute-geforce.
5. Sichere ‘pg_hba.conf’ Und UFW: Bearbeite pg_hba.conf, um nur die tatsächlich benötigten Anwendungs-IPs zuzulassen, mit ‘scram-sha-256’ als Authentifizierungsmethode. Konfiguriere UFW so, dass Port 5432 nur von diesen IPs zugelassen wird. Verwende einen SSH-Tunnel für Admin-Tools (und bitte öffne 5432 nicht für das öffentliche Internet).

Probiere dies von einem anderen Gerät aus: psql -h <vps-ip> -U postgres.

Ein Timeout oder eine abgelehnte Verbindung von einer nicht autorisierten IP bedeutet normalerweise, dass Dein Listener und Deine Firewall-Regeln ihre Arbeit machen. Eine Passwortaufforderung aus dem öffentlichen Internet bedeutet, dass etwas falsch konfiguriert ist. Sobald Postgres läuft, ist die Konfiguration nur die halbe Arbeit.

Wie Sichert Man PostgreSQL Auf Einem VPS?

PostgreSQL auf einem VPS wird auf drei Ebenen gesichert, plus Rollenhygiene und Patch-Rhythmus.

1. Authentifizierung: Verwende scram-sha-256 für neue Installationen und entferne veraltete md5-Regeln aus pg_hba.conf. Die Dokumentation von PostgreSQL warnt jetzt, dass die Unterstützung von MD5-verschlüsselten Passwörtern veraltet ist und in einer zukünftigen Version entfernt wird.
2. Netzwerk: Binde PostgreSQL an ‘localhost’, eine private IP oder eine Schnittstelle, die nur von deinen Anwendungsservern erreichbar ist. Vermeide es, sie an eine öffentlich erreichbare Schnittstelle zu binden. Lege UFW darüber und erlaube Port 5432 nur von vertrauenswürdigen Anwendungs-IPs.
3. Verschlüsselung im Transit: Aktiviere TLS für jede Verbindung, die eine Netzwerkgrenze überschreitet. Setze ssl = on in postgresql.conf, dann verwende hostssl … scram-sha-256 Regeln in pg_hba.conf, damit Clients nicht stillschweigend auf Nicht-TLS-Verbindungen zurückfallen können. Selbstsignierte Zertifikate sind für internen Verkehr akzeptabel, wenn die Clients sie richtig überprüfen.
4. Rollen: Anwendungsverbindungen sollten eine Rolle mit minimalen Rechten verwenden, die nur die für das Schema der Anwendung benötigten Rechte hat. Der Superuser ist für Migrationen und Notfälle gedacht.
5. Patching: Verwende das PGDG apt-Repository für aktuelle PostgreSQL-Pakete. Aktiviere unaufgeforderte Sicherheitsupdates für das Betriebssystem, plane aber PostgreSQL-Updates gezielt, damit ein unerwarteter Neustart nicht zum Vorfall der Woche wird. 

Deine Sicherheitscheckliste:

• Verwende nur scram-sha-256; deaktiviere md5.
• Binde ‚listen_addresses‘ an localhost oder private IP.
• UFW-Regeln erlauben 5432 nur von vertrauenswürdigen IPs.
• SSL/TLS bei jeder netzwerkübergreifenden Verbindung aktiviert.
• App verbindet sich als rolle mit den geringsten Rechten, niemals als ‚postgres‘.
• Automatische Sicherheitsupdates aktiviert.
• Keine ‚host all all 0.0.0.0/0 md5‘ Zeilen irgendwo in ‚pg_hba.conf‘, niemals.

Das letzte Stichwort ist die warnende Geschichte.

Der öffentlich zugängliche Port 5432 mit schwachen Anmeldeinformationen ist ein bekanntes Ziel für Cryptominer und Brute-Force-Angriffe. Offene PostgreSQL-Instanzen werden kontinuierlich von automatisierten Bots gescannt, die nach Standardkonten, durchgesickerten Passwörtern oder permissiven pg_hba.conf-Regeln suchen.

Öffentlich erreichbare Postgres-Instanzen mit schwacher Authentifizierung werden häufig erschreckend schnell kompromittiert. Eine Datenbank, die direkt dem Internet ausgesetzt ist, ohne angemessene Netzwerkkontrollen, TLS und Rollenisolation, ist die Art von Fehler, die zu einem Vorfallbericht führt. Eine ordnungsgemäß konfigurierte Datenbank ist immer noch einen Festplattenausfall von einem Datenverlust entfernt.

Wie Sichert Und Repliziert Man PostgreSQL Auf Einem VPS?

PostgreSQL-Backups auf einem VPS verwenden einen von drei Mechanismen, die je nach dem zu schützenden Fehler ausgewählt werden. Logische Backups über pg_dump für die Portabilität, physische Backups über pg_basebackup plus WAL-Archivierung für die Wiederherstellung zu einem bestimmten Zeitpunkt und Streaming-Replikation für hohe Verfügbarkeit.

Logische Backups unterstützen Migrationen, partielle Wiederherstellungen und Entwicklungsaktualisierungen. Führe pg_dump –format=custom –file=mydb.dump mydb_prod von einem täglichen Cron Job aus. Das benutzerdefinierte Format komprimiert gut und unterstützt zusammen mit dem Verzeichnisformat die parallelen und selektiven Wiederherstellungsoptionen von pg_restore. Übertrage den Dump in einen externen VPS Object Storage (DreamObjects, S3-kompatibel).

Physische Backups ermöglichen vollständige Systemwiederherstellungen und Wiederherstellungen zu einem bestimmten Zeitpunkt. pg_basebackup zusammen mit kontinuierlichem Write-Ahead Log (WAL)-Archivieren ermöglicht es dir, dich auf jeden Moment zwischen dem letzten Basis-Backup und dem neuesten WAL-Segment zu erholen, die produktionsreife Option, wenn die Toleranz gegenüber Datenverlust Sekunden und nicht Stunden beträgt.

Streaming-Replikation ist die dritte Option. Eine Lese-Replik auf einem zweiten VPS ist eine heiße Standby-Lösung für leseintensive Arbeitslasten oder ein schnelles Failover-Ziel. Die Einrichtung der Datenbankreplikation kostet einen zweiten VPS, begrenzt jedoch deine maximal mögliche Ausfallzeit auf Minuten.

Mechanismus	Was Du Erhältst	Was Es Kostet
pg_dump + Cron + Off-VPS-Speicher	Tägliches logisches Backup, portabel	Wiederherstellungslatenz, nicht zeitpunktgenau
pg_basebackup + WAL-Archivierung	Physisches Backup mit zeitpunktgenauer Wiederherstellung	Speicher- und Betriebskomplexität
Streaming-Replikation	Heißes Standby, nahezu null Recovery Point Objective (RPO), Lese-Skalierung	Zweites VPS plus Replikationsmanagement

Monatlicher Wiederherstellungstest. Verwaltete Dienste integrieren all dies, und das ist ein Teil dessen, was die Einsparungen durch Selbsthosting zurückkaufen. Wenn Du bereits bei einem verwalteten Anbieter bist, ist der Weg heraus einfacher, als es aussieht.

Wie Migrierst Du Von RDS, Supabase Oder Neon Zu Einem VPS?

Du migrierst von einem verwalteten Postgres-Anbieter zu einem VPS in vier Schritten.

1. Bereitstellung des Ziel-VPS: Die Hauptversion von Postgres exakt anpassen. Installiere PostgreSQL auf dem neuen VPS gemäß den obigen Schritten, dann erstelle zuvor die Anwendungsrolle und die Datenbank.
2. Dump von der Quelle: 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 Rollenzuweisungen, die sich selten sauber auf einem neuen Host wiederherstellen lassen.
3. Wiederherstellung auf das Ziel: Führe pg_restore –dbname=myapp_prod –jobs=4 –no-owner –no-privileges src.dump aus. Achte auf Warnungen bezüglich Erweiterungen. RDS, Supabase und Neon aktivieren oft Erweiterungen, die möglicherweise nicht auf einem Standard-Postgres existieren. Installiere kompatible Erweiterungen aus PGDG-Paketen oder postgresql-contrib, bevor du wiederherstellst.
4. Wechsel und Verifizierung der Verbindungszeichenfolge: Richte zunächst eine Staging-Umgebung auf dem neuen VPS ein, führe deine Testsuite aus, dann validiere repräsentative Produktionsabfragen und Anwendungsabläufe, bevor du die Produktionsverbindungszeichenfolge umschaltest. Für Anwendungen mit geringem Schreibzugriff ist ein kurzes Wartungsfenster während des endgültigen Umstiegs oft einfacher als die Einrichtung einer Replikation. Halte die Quelldatenbank mehrere Tage online und schreibgeschützt als Ziel für einen Rollback.

Welche Änderungen durch Anbieter?

1. Von RDS: RDS-spezifische Rollen (‘rds_superuser,’ ‘rdsadmin’) existieren nicht in einem Standard-Postgres; –no-owner und –no-privileges decken das meiste ab. Einige von RDS verwaltete Erweiterungen benötigen eine manuelle Installation, und der Datenaustausch aus AWS während des Dumps ist kostenpflichtig.
2. Von Supabase: Das Postgres ist echtes Postgres, aber Supabases Authentifizierung, Speicher und Edge-Schichten migrieren nicht. Dein Anwendungsschema schon. Ersetze diese Schichten durch selbstgehostete Äquivalente, bevor du umstellst.
3. Von Neon: Verzweigungen verschwinden nach der Migration; plane stattdessen mit Backups. Dump-und-Restore ist unkompliziert, aber betriebliche Gewohnheiten wie sofortige Verzweigungen benötigen einen Ersatz-Workflow.

Die Migration selbst dauert in der Regel weniger Zeit als das Auswählen des VPS-Plans. Die realistische Ausfallzeit beträgt Minuten für kleine Datenbanken und ist länger mit WAL-Wiedergabe für große. Die meisten Installationen enden hier, aber es gibt ein Szenario, das Dich weiterbringt…

Wann Solltest Du PgBouncer Hinzufügen Oder Bei Vanilla Postgres Bleiben?

Die meisten Apps auf einem 4 GB VPS benötigen zu Beginn keinen Verbindungspooler. Füge PgBouncer hinzu, wenn die gleichzeitigen Verbindungen etwa 100 überschreiten oder dein Anwendungsstack bei jeder Anfrage eine neue Verbindung öffnet.

PostgreSQL-Verbindungen sind aufwändig, da jede eine vollständige Betriebssystemprozess ist. Mit 4 GB RAM möchtest Du nicht Hunderte von untätigen Verbindungen haben, die Speicher verbrauchen. Der Pooler hält die teuren Postgres-Verbindungen auf seiner Seite und gibt preiswerte, kurzlebige Verbindungen an Deine App auf der anderen Seite weiter.

Zwei Pooling-Modi sind von Bedeutung:

• Session-Pooling: Jeder Client erhält eine Serververbindung für die Sitzung. Sicher für jede Anwendung, keine semantischen Änderungen, geringerer Durchsatzgewinn.
• Transaktions-Pooling: Jeder Client erhält eine Serververbindung für eine Transaktion. Großer Durchsatzgewinn. Du verlierst Funktionen, die auf dem Sitzungszustand basieren (vorbereitete Anweisungen, Beratungssperren, ‘LISTEN’/’NOTIFY’), es sei denn, die Anwendung ist darauf ausgelegt, dies zu erwarten.

Die meisten kleinen SaaS-Apps mit einem verbindungspoolenden ORM funktionieren ohne PgBouncer gut, bis sie es nicht mehr tun. Das Signal, dass Du die Grenze überschritten hast, sind ‘FATAL: too many connections’ Fehler oder Speicherdruck durch untätige Verbindungen.

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

Ja, Du wirst wissen, wann Du es brauchst.

Die Letzte Entscheidung Treffen

Die Kostenlücke ist real genug, um die Rechnung gegen deine eigene abzuwägen. Aber die Einrichtung ist nicht der schwierige Teil.

Der schwierige Teil ist die operative Arbeit, für die die verwaltete Rechnung bezahlt wurde. Backups, Wiederherstellungsübungen, Patching und Überwachung.

Mach auf jeden Fall einen tiefen Atemzug, bevor Du die nächste Rechnung öffnest.

Häufig Gestellte Fragen Zu PostgreSQL Auf Einem VPS

Wie viel RAM benötigt PostgreSQL auf einem VPS?

PostgreSQL läuft auf 1 bis 2 GB für kleine Arbeitslasten und komfortabel auf 4 GB für die meisten Produktionsanwendungsdatenbanken. Schwerere Datensätze, mehr gleichzeitige Verbindungen oder Analyseaufgaben erhöhen den Bedarf auf 8 GB oder mehr.

Kann ich PostgreSQL auf einem 2 GB VPS betreiben?

Ja, Du kannst PostgreSQL auf einem 2 GB VPS für kleine Apps, Entwicklungsumgebungen und Projekte mit geringem Traffic betreiben. Ein 2 GB-System bietet wenig Spielraum für Caching, daher sinkt die Abfrageleistung, sobald Deine Daten den Speicher überschreiten. Für Produktivlasten ist 4 GB eine sicherere Basis.

Ist Selbsthosting Von PostgreSQL Auf Einem VPS Günstiger Als RDS Oder Supabase?

Ja, das Selbsthosting von PostgreSQL auf einem VPS ist günstiger als RDS oder Supabase für die meisten gleichbleibenden Arbeitslasten. Ein 4 GB VPS läuft häufig zu einem Bruchteil der entsprechenden RDS-, Supabase Pro- oder Neon Scale-Spezifikation, sobald Speicher, Backups und Egress berücksichtigt werden. Der Kompromiss besteht darin, dass Du die Datenbank selbst betreibst.

Wie lege ich PostgreSQL auf einem VPS sicher frei?

Setze Port 5432 nicht dem öffentlichen Internet aus. Binde PostgreSQL an localhost oder eine private IP, fordere scram-sha-256-Authentifizierung und nutze SSH-Tunnel für Admin-Tools, anstatt 5432 für deinen Laptop zu öffnen. Öffentlicher 5432 mit schwacher Authentifizierung ist ein bekanntes Ziel für Kryptominer.

Muss ich Docker für PostgreSQL auf einem VPS verwenden?

Nein, Docker ist nicht erforderlich. Das offizielle PGDG apt Repository installiert PostgreSQL als einen nativen Systemdienst, was die einfachste Produktionsgradeinrichtung darstellt. Docker ist sinnvoll, wenn Du bereits andere Container betreibst.

Wie kann ich PostgreSQL auf einem VPS sichern?

Führe pg_dump –format=custom täglich nach einem Cron-Zeitplan aus und speichere die Ausgabe außerhalb des VPS in einem S3-kompatiblen Objektspeicher. Verwende pg_basebackup plus WAL-Archivierung für eine punktgenaue Wiederherstellung, wenn sekundenlang Datenverlust eine Rolle spielt. Stelle monatlich einen Wiederherstellungstest durch.

Welchen Plan Sollte Ich Für Das Selbst-Hosting Von PostgreSQL Bei DreamHost Wählen?

Der VPS Stack 4 Tarif von DreamHost (4 GB RAM) ist die empfohlene Basis für die meisten Produktionsanwendungsdatenbanken. Wähle Stack 8 (8 GB) für größere Datensätze oder hohe Parallelität und Stack 16 für Postgres zusammen mit anderen ressourcenintensiven Diensten.

Sollte ich PgBouncer mit PostgreSQL auf einem kleinen VPS verwenden?

Die meisten Apps auf einem 4 GB VPS benötigen zu Beginn keinen PgBouncer. Füge einen Connection Pooler hinzu, wenn gleichzeitige Verbindungen sich der Zahl 100 nähern, oder wenn deine App bei jeder Anfrage eine neue Verbindung öffnet.