Mehrere Datenbankinstanzen auf einem Server selbst betreiben

Das Versprechen des Datenbank-Self-Hostings

Cloudverwaltete Datenbanken sind praktisch – bis die Rechnung kommt. Für Teams, die mehrere Projekte betreiben, jedes mit einer eigenen Postgres-Instanz, verschiebt sich die Kostenrechnung dramatisch, sobald man drei oder vier Datenbanken überschreitet.

In der Praxis ist es jedoch nicht damit getan, einfach mehr Container zu starten, wenn man mehrere Datenbankinstanzen auf einem einzigen Server unterbringen möchte. Speicherkonflikte, Disk-I/O-Konflikte und die Orchestrierung von Backups werden zu ernstzunehmenden Problemen, die verwaltete Dienste stillschweigend für Sie lösen.

Unser Setup: Mehrere Supabase-Stacks auf einem Server

Wir betreiben mehrere vollständige Supabase-Stacks – jeweils bestehend aus Postgres, GoTrue, PostgREST, Realtime und Storage – auf einem einzigen dedizierten Server. Der Server ist eine 16-vCPU-Maschine mit 32 GB RAM in einem europäischen Rechenzentrum, vollständig über Docker Compose orchestriert.

Jeder Stack erhält seine eigene Compose-Datei, seinen eigenen Netzwerk-Namespace und sein eigenes Daten-Volume. Die entscheidende Architekturentscheidung: kein gemeinsamer Postgres-Cluster. Jedes Projekt erhält eine vollständig isolierte Datenbankinstanz. Der Overhead mehrerer Postgres-Prozesse ist real – etwa 200–400 MB pro inaktiver Instanz – aber die operative Einfachheit der vollständigen Isolation überwiegt die Ressourcenkosten.

Ressourcenlimits, die wirklich wichtig sind

services:
  db:
    image: supabase/postgres:15.6
    deploy:
      resources:
        limits:
          memory: 2G
          cpus: '2.0'
        reservations:
          memory: 512M
          cpus: '0.5'

Docker-Ressourcenlimits sind die erste Verteidigungslinie. Ohne sie kann eine einzige außer Kontrolle geratene Abfrage jede andere Datenbank auf der Maschine aushungern. Die Reservierung stellt sicher, dass jede Instanz immer eine Mindestzuweisung hat, selbst unter Konkurrenzbedingungen.

Backup-Orchestrierung über Instanzen hinweg

Das Problem bei mehreren Datenbanken ist nicht das Sichern selbst – pg_dump erledigt das zuverlässig. Das Problem ist die Orchestrierung der Backups, damit sie nicht alle gleichzeitig laufen und die Disk-I/O sättigen.

Wir staffeln Backups mit einem einfachen Cron-Zeitplan mit Versätzen. Instanz A sichert um 02:00 Uhr, Instanz B um 02:15 Uhr, Instanz C um 02:30 Uhr. Jedes Backup wird durch gzip geleitet und in Object Storage hochgeladen. Gesamtes Backup-Fenster für alle Instanzen: unter 45 Minuten.

Monitoring ohne Monitoring-Stack

Eine häufige Falle: Prometheus, Grafana und AlertManager einzusetzen, um einen Server zu überwachen – und damit die Ressourcen zu verbrauchen, die man schützen möchte. In unserem Maßstab funktioniert ein leichtgewichtiger Ansatz besser.

Ein Shell-Skript läuft alle fünf Minuten via Cron, überprüft jede Postgres-Instanz mit pg_isready, misst die Festplattennutzung pro Volume und sendet eine Zusammenfassung an einen Benachrichtigungs-Endpunkt, wenn ein Schwellenwert überschritten wird. Gesamter Ressourcenverbrauch: vernachlässigbar.

Wann man mit dem Self-Hosting aufhören sollte

Mehrere Datenbanken selbst zu betreiben macht Sinn, wenn das Team Postgres-Operationen versteht, die Workloads vorhersehbar sind und die Kosteneinsparungen den operativen Aufwand rechtfertigen. In dem Moment, in dem sich eine dieser Bedingungen ändert – schnell wachsende Skalierungsanforderungen, Compliance-Mandate für verwaltete Dienste oder Teamfluktuation – verschiebt sich die Rechnung zurück zu verwalteten Angeboten.

Die besten Infrastrukturentscheidungen sind umkehrbar. Docker-Volumes können exportiert werden, pg_dump-Dateien können überall wiederhergestellt werden, und die Anwendungsschicht sollte nicht wissen, wo ihre Datenbank lebt. Diese Portabilität ist der eigentliche Wert des containerisierten Ansatzes – nicht die Kosteneinsparungen.