e.V.
Infrastruktur · Eigener Dienst · Live

Postgres

17 separate Datenbanken

Eine Postgres-Datenbank pro Service — schema-isoliert, mit Drizzle-Migrationen, keine geteilten Tabellen.

Ersetzt
Supabase, Neon, Amazon Aurora, RDS, PlanetScale
Der Dienst

Jeder Service besitzt seine eigene Datenbank. Nicht ein gemeinsames Schema mit Foreign-Keys über Service-Grenzen, sondern wirklich 17 unabhängige Postgres-Instanzen — oder genauer: 17 Datenbanken, die sich einen Postgres-Cluster teilen, aber per pgSchema voneinander isoliert sind und über ihre eigene Credential-Wand sprechen.

Warum nicht eine große Datenbank? Weil ein Service-Refactor dann nicht „eine Spalte hinzufügen” wäre, sondern „die ganze Welt updaten”. Weil ein Service-Ausfall dann alle anderen mitreißen würde. Weil ein Backup-Restore dann eine politische Frage wäre.

Wer einen Service löscht, löscht eine ganze DB. Das ist die direkte Konsequenz aus dem Service-Per-Repo-Pattern. Die DSGVO-Auskunft pro Mitglied läuft über mana-admin und stellt eine Anfrage an jede relevante Service-DB einzeln.

Migrations: Drizzle-Migrationen, pro Service versioniert, beim Container-Start automatisch angewendet (Pattern aus MIGRATIONS_BOOTSTRAP.md). Wer den Container neu deployed, hat nach 30 Sekunden die neuen Spalten.

PostGIS: Die Plant-Datenbank von Herbatrium und der Geo-Service nutzen die PostGIS-Erweiterung — eigene Container, eigene Volumes.

Cross-Link

Plattform-Services, die hier aufsitzen

Diese Services nennen Postgres in ihrem Infrastruktur-Frontmatter — sie sind direkt von diesem Baustein abhängig.

Grundsätze

Was Postgres für den Verein verkörpert

  • Datensouveränität
    Verwahrer statt Eigentümer.
  • Langlebigkeit
    Bewährte Stacks, gute Doku.
  • Eigenbetrieb
    Eigene Infrastruktur, quelloffener Stack.
  • Offenheit
    Code und Mittelverwendung öffentlich.

Postgres ist ein Baustein der Vereins-Infrastruktur — eine von drei Schichten unter den Plattform-Services und Apps.