Wie unterscheidet sich das von deinem allgemeinen Datenbank-Anwendungsfall?

Die allgemeine Datenbankseite deckt das ganze Bild ab — Postgres oder Redis, Dimensionierung, wann eine geteilte Maschine das falsche Werkzeug ist. Diese hier ist speziell PostgreSQL: Superuser, die volle postgresql.conf, jede gewünschte Erweiterung, die Wahl deiner Hauptversion und pg_dump / WAL-Backups nach deinem eigenen Zeitplan. Willst du gezielt selbst gehostetes Postgres, ist das die tiefe Version; die allgemeine Seite ist der Überblick.

Welche Erweiterungen kann ich installieren?

Alle davon — das ist der Sinn des Selbst-Hostens. pgvector für Embeddings und semantische Suche, PostGIS für Geodaten, TimescaleDB für Zeitreihen, pg_cron, pg_stat_statements. Managed-Tarife beschränken oft die Erweiterungsliste oder sperren sie hinter einem höheren Plan; mit Superuser auf deiner eigenen Maschine installierst du, was deine Arbeitslast braucht.

Wie viel RAM braucht PostgreSQL?

Für die Datenbank einer App sind 1,7–2 GB Working-Set realistisch, also passt Small ($8/Monat). Mehr Apps, echte Produktions-Nebenläufigkeit oder ein großer pgvector-Index drängen dich zu Medium ($12) oder höher. Stimme shared_buffers und work_mem auf die Maschine ab; dieses Tuning ist von vornherein ein großer Grund, selbst zu hosten.

Wie verbinden sich andere Server sicher?

Binde Postgres an die richtige Schnittstelle, öffne 5432 nur für die konkreten IPs, die es brauchen (niemals 0.0.0.0/0), verlange TLS und nimm einen Tarif mit dedizierter IPv4, damit die Adresse stabil und routbar ist. Bedient die Datenbank nur eine App auf derselben Maschine, halte sie auf localhost und exponiere nichts.

Verlangt ihr Ausweis oder Karte?

Nein. E-Mail zum Registrieren, Zahlung in USDC oder USDT. Root in etwa einer Minute, dann ist Postgres nur ein paar Befehle entfernt.

VPS für eine PostgreSQL-Datenbank (selbst gehostet, volle Kontrolle)

Hoste PostgreSQL selbst auf einem VPS mit Superuser und der ganzen postgresql.conf — jede Erweiterung (pgvector, PostGIS, TimescaleDB), deine eigene Version, deine eigenen Backups. Eine Alternative zu Managed-Postgres, die du vollständig kontrollierst. Kein KYC, Zahlung in Krypto. Ab $8/Monat.

Es gibt einen Moment, in dem Managed-PostgreSQL aufhört, bequem zu sein: Du willst eine Erweiterung, die der Tarif nicht bietet, du willst den echten Query-Plan sehen und work_mem tunen, du willst Superuser. Wenn du Postgres besitzen willst — die Konfiguration, die Version, die Erweiterungen, den Backup-Zeitplan — ist ein VPS mit vollem Root die ehrliche Antwort. Das ist das PostgreSQL-spezifische Setup; für das breitere Bild „eine Datenbank selbst hosten" (Postgres vs. Redis, wo eine geteilte Maschine falsch ist) siehe den allgemeinen Datenbank-Anwendungsfall.

Warum PostgreSQL selbst hosten

Auf deiner eigenen Maschine bekommst du, was Managed-Tarife rationieren:

Die ganze postgresql.conf — shared_buffers, work_mem, max_connections, WAL-Einstellungen, auf deine Arbeitslast abgestimmt, kein Anbieter-Default.
Jede Erweiterung. pgvector für Embeddings, PostGIS für Geodaten, TimescaleDB für Zeitreihen, pg_cron, pg_stat_statements — installiere, was du brauchst. Genau hier sagt ein Managed-Tarif am häufigsten nein.
Deine Hauptversion, aktualisiert nach deinem Zeitplan, nicht dem des Anbieters.
Superuser und das OS darunter — verschiebe das Datenverzeichnis, tune den Kernel, betreibe Streaming-Replikation zu einer zweiten Maschine.

Ist pgvector der Grund, warum du hier bist, beachte: Postgres-plus-pgvector ist ein vollständiger Vektorspeicher auf einer Maschine — derselbe Baustein hinter einem selbst gehosteten RAG-Stack und Agenten-Gedächtnis.

Richte es ein (Ubuntu 24.04, Docker)

# docker-compose.yml — PostgreSQL 16 (+ pgvector via the pgvector image)
services:
  db:
    image: pgvector/pgvector:pg16
    restart: always
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: change-me-strong
      POSTGRES_DB: app
    command: ["postgres", "-c", "shared_buffers=512MB", "-c", "work_mem=32MB"]
    volumes: ["/srv/pg:/var/lib/postgresql/data"]
    ports: ["127.0.0.1:5432:5432"]   # localhost only; see below to expose safely

docker compose up -d
docker compose exec db psql -U app -c "CREATE EXTENSION IF NOT EXISTS vector;"

An 127.0.0.1 gebunden, bedient es eine App auf derselben Maschine, ohne etwas zu exponieren. Um andere Server hereinzulassen — das ist der nächste Abschnitt.

Andere Server verbinden lassen — sicher

Sobald eine andere Maschine die Datenbank braucht, ändern sich zwei Dinge:

Eine stabile, routbare Adresse — ein Tarif mit dedizierter IPv4 (Small-IP $16, Medium-IP $20). NAT-Tarife teilen sich eine ausgehende IP, gut für ausgehend, aber nicht dafür, eine Datenbank zu sein, die andere anwählen.
Firewall es hart. Öffne 5432 nur für die konkreten Client-IPs, niemals 0.0.0.0/0, und verlange TLS. Ein offener Postgres-Port im öffentlichen Internet wird in Minuten gefunden — sperre ihn mit einer UFW-Firewall ab.

Backups sind dein Job

Selbst-Hosten heißt, Backups liegen bei dir, und die Regel ist: mach sie, bevor du sie brauchst. pg_dump per Cron für logische Backups oder WAL-Archivierung für Point-in-Time-Recovery bei allem, was dir wichtig ist. Verschiffe die Dumps von der Maschine und teste eine Wiederherstellung mindestens einmal — ein nie wiederhergestelltes Backup ist eine Hoffnung, kein Backup. Ein Managed-Backups-Add-on ist verfügbar, wenn du es lieber nicht selbst betreibst.

Warum EQVPS für PostgreSQL

Voller Root, Superuser, deine Konfiguration — ab $8/Monat, NVMe (RAID1), das zählt, sobald eine Datenbank und ihr WAL gleichzeitig schreiben.
Kein KYC, Krypto-Zahlung. E-Mail zum Registrieren, USDC/USDT zum Bezahlen.
EU (Deutschland, Finnland), Root in ~60 Sekunden. Bring dein Schema mit und leg los.

Allgemeiner Datenbank-Anwendungsfall (Postgres/Redis-Überblick) → · Selbst gehostetes RAG im Maßstab →