Wie viel RAM braucht eine selbst gehostete Datenbank?

Für eine App — eine Postgres- oder Redis-Instanz plus ihr Backend — sind 1,7–2 GB ein realistisches Arbeitsset, also passt Small (8 $). Mehrere Apps oder eine Produktionsdatenbank mit echter Nebenläufigkeit drücken dich zu Medium (12 $), und wenn andere Maschinen sie erreichen müssen, zu einem Plan mit dedizierter IP. Dimensioniere nach Arbeitsset und Verbindungsanzahl, nicht nach Hoffnung.

Warum selbst hosten statt einer verwalteten Datenbank?

Kontrolle. Du bekommst die ganze postgresql.conf, Superuser und jede Erweiterung, die du willst — pgvector, PostGIS, TimescaleDB, pg_cron — Dinge, die verwaltete Stufen oft sperren oder extra berechnen. Der Kompromiss ist, dass Backups, Tuning und Upgrades deine sind, sie durchzuführen. Wenn du die Maschine besitzen willst, ist das der Punkt.

Ist ein geteilter VPS für eine Produktionsdatenbank in Ordnung?

Für eine kleine bis mittlere App, ja. Für schweres OLTP — Hunderte Transaktionen pro Sekunde, latenzkritische Schreibvorgänge — ist eine Maschine mit geteilter vCPU das falsche Werkzeug, und wir sagen das lieber, als dir eine zu verkaufen. Festplatten-I/O und ein garantierter Takt zählen dort, und geteilte Pläne versprechen keines von beiden.

Wie lasse ich meine anderen Server sich mit der Datenbank verbinden?

Binde Postgres an die richtige Schnittstelle, öffne den Port nur für die IPs, die ihn brauchen, und nutze einen Plan mit dedizierter IPv4, damit die Adresse stabil und erreichbar ist. Lege 5432 nie ins ganze Internet offen — Firewall sie auf deine App-Server und verlange TLS.

Muss ich euch einen Ausweis geben?

Nein. E-Mail zum Registrieren, USDC oder USDT zum Bezahlen. Keine Dokumente, root in etwa einer Minute.

VPS für eine Datenbank

Hoste PostgreSQL oder Redis selbst auf einem VPS mit vollem root — die ganze postgresql.conf, Erweiterungen, die ein verwalteter Dienst dich nicht installieren lässt, und ehrliche Grenzen, was eine geteilte Maschine verkraften kann und was nicht. Ab 8 $/Mon.

Es gibt einen bestimmten Moment, in dem eine verwaltete Datenbank aufhört, bequem zu sein, und anfängt, eine Wand zu sein. Du willst eine Erweiterung, die die Stufe nicht bietet. Du willst den tatsächlichen Query-Plan sehen und work_mem tunen. Du willst einen Superuser. Ein verwalteter Dienst ist ein großartiger Standard genau bis du das Ding besitzen musst — und dann ist ein VPS mit vollem root die ehrliche Antwort.

Auf dieser Seite geht es darum, dein eigenes PostgreSQL oder Redis korrekt zu betreiben und klar zu sein, wo eine geteilte Maschine die richtige Wahl ist und wo nicht.

Was eine Datenbank tatsächlich braucht

Datenbanken kümmern sich um zwei Dinge, die ein Game-Server nicht tut: Speicher für das Arbeitsset und Festplatten-I/O. Die grobe Form:

Eine App — eine Postgres- (oder Redis-)Instanz plus ein Backend-Dienst. Das Arbeitsset ist meist 1,7–2 GB. Small (8 $) bewältigt es ohne Drama.
Ein paar Apps oder echte Produktions-Nebenläufigkeit — mehr Verbindungen, größere Caches, Hintergrund-Jobs. Medium (12 $) gibt dir den Spielraum.
Andere Maschinen müssen sie erreichen — du willst eine stabile, routbare Adresse, also einen Plan mit dedizierter IPv4 (Small-IP 16 $ und aufwärts). Mehr dazu unten.

Redis ist noch leichter — es ist speichergebunden, also dimensioniere den Plan auf deinen Datensatz plus Overhead und du bist fertig. Postgres ist das, was ein wenig Tuning belohnt.

Der echte Grund, selbst zu hosten: Kontrolle

Hier verdient ein VPS seinen Platz. Auf deiner eigenen Maschine bekommst du:

Die ganze postgresql.conf — shared_buffers, work_mem, max_connections, WAL-Einstellungen, alles davon, auf deinen Workload getunt statt auf die Standardwerte eines Anbieters.
Jede Erweiterung. pgvector für Embeddings und semantische Suche, PostGIS für Geodaten, TimescaleDB für Zeitreihen, pg_cron, pg_stat_statements — installiere, was du brauchst. Verwaltete Stufen beschränken häufig die Erweiterungsliste oder gaten sie hinter einem höheren Plan.
Superuser und das OS darunter. Du kannst das Datenverzeichnis verschieben, den Kernel tunen, pg_dump nach deinem eigenen Zeitplan ausführen und Streaming-Replikation zu einer anderen Maschine einrichten, wenn du sie willst.

Wenn nichts davon für dich zählt, ist eine verwaltete Datenbank wirklich in Ordnung und du solltest eine nutzen. Diese Seite ist für den Fall, in dem es zählt.

Wo eine geteilte Maschine das falsche Werkzeug ist

Ehrlich darüber: ein VPS mit geteilter vCPU ist nicht für schweres OLTP gebaut — Hunderte Transaktionen pro Sekunde mit latenzkritischen Schreibvorgängen. Dieser Workload lebt oder stirbt an garantiertem Festplatten-I/O und einem stetigen Takt, und geteilte Pläne versprechen keines. Wenn das du bist, willst du dedizierte Hardware, und wir sagen es dir lieber jetzt, als deiner p99-Latenz zuzusehen, wie sie uns beide blamiert.

Für den weit häufigeren Fall — eine Datenbank hinter einer App, ein internes Tool, ein Analytics-Speicher, ein Cache — ist ein geteilter Plan genau richtig.

Backups sind nicht optional

Selbst-Hosten bedeutet, Backups sind dein Job, und die eine Regel ist: mach sie, bevor du sie brauchst. Für Postgres pg_dump per Cron für logische Backups oder WAL-Archivierung für Point-in-Time-Recovery bei allem, was dir tatsächlich wichtig ist. Verschiff die Dumps von der Maschine weg — zu Object-Storage oder einem anderen Server — damit eine tote Festplatte die Backups nicht mitnimmt. Teste eine Wiederherstellung mindestens einmal. Ein Backup, das du nie wiederhergestellt hast, ist eine Hoffnung, kein Backup.

Andere Server sich verbinden lassen

Wenn die Datenbank nur eine App auf derselben Maschine bedient, binde sie an localhost und du bist fertig — nichts offenzulegen. In dem Moment, in dem eine andere Maschine hinein muss, ändern sich zwei Dinge:

Du brauchst eine stabile, routbare Adresse — das ist ein Plan mit dedizierter IPv4 (Small-IP 16 $, Medium-IP 20 $). NAT-Pläne teilen eine Adresse, was für ausgehend in Ordnung ist, aber nicht dafür, eine Datenbank zu sein, in die andere Server sich einwählen.
Du firewallst sie hart. Öffne 5432 (oder 6379) nur für die spezifischen IPs, die sie brauchen, nie für 0.0.0.0/0, und verlange TLS. Ein offener Postgres-Port im öffentlichen Internet wird in Minuten gefunden.

Den Plan wählen

Setup	Plan
DB hinter einer App, nur localhost	Small (8 $)
Ein paar Apps / Produktions-Nebenläufigkeit	Medium (12 $)
Andere Server müssen sich verbinden	Small-IP (16 $) / Medium-IP (20 $)
Schweres OLTP, Hunderte TPS	dedizierte Hardware, kein geteilter VPS

Die meisten selbst gehosteten Datenbanken beginnen auf Small und wachsen in Medium oder einen Plan mit dedizierter IP hinein, wenn sie mehr Apps oder externe Clients übernehmen.

Warum hier

Volles root bedeutet, es ist deine Datenbank, bis ganz unten — jede Config-Zeile, jede Erweiterung, dein eigener Backup-Zeitplan, keine Stufe, die entscheidet, was du installieren darfst. Die Zahlung ist Krypto (USDC oder USDT auf Base, Ethereum oder Polygon), kein KYC, keine Dokumente. Root in etwa 60 Sekunden nach der Zahlung, und du kannst Postgres ein paar Minuten später Verbindungen annehmen lassen.

Die ehrliche Zusammenfassung: hoste selbst, wenn du Kontrolle willst — Erweiterungen, Tuning, Superuser — und wenn dein Workload moderat ist. Für die Datenbank einer kleinen bis mittleren App ist ein geteilter Plan das richtige Werkzeug. Für Hunderte TPS latenzkritisches OLTP ist er es nicht, und wir sagen das. Bereit? Wähle einen Plan.