PostgreSQL Datenbank Cluster

PostgreSQL ist ist eine hochverfügbare, robuste Datenbankplattform. Ob Community-Plattform, Bildungsangebote oder digitale Services: Alles, was wir bei 4future.one aufbauen, basiert auf Daten – und darauf, dass diese immer verfügbar und sicher sind.

Daten sind das Rückgrat digitaler Systeme. Ohne sie funktioniert nichts: keine Anmeldung, keine Inhalte, keine Prozesse. Deshalb ist die Wahl der richtigen Datenbankinfrastruktur keine Nebensache, sondern ein zentraler strategischer Baustein.

Warum wir überhaupt über Datenbanken reden sollten…

Fast jede digitale Aktion speichert oder liest Daten:
📬 Ein Benutzer registriert sich
📅 Eine Veranstaltung wird gebucht
🧠 Lernfortschritt wird gespeichert

Im Hintergrund all dieser Funktionen stehen Datenbanken. Und die müssen immer verfügbar sein – auch bei Wartungsarbeiten oder wenn ein System ausfällt. Genau deshalb bauen wir bei 4future.one eine hochverfügbare, ausfallsichere und Datenbankinfrastruktur auf, die wir auch selbst unter Kontrolle haben. 

Zwei Datenbanken – je nach Einsatzzweck

Je nach Anwendung und Anforderung setzen wir auf zwei bewährte Open-Source-Datenbanksysteme:

🐘 PostgreSQL

Die robuste, skalierbare und moderne Datenbank mit Fokus auf Integrität, komplexe Abfragen und Hochverfügbarkeit.
Eingesetzt bei:

• Benutzerverwaltung

• zentrale Plattformdienste

• Authentifizierungssysteme 

• Anwendungen mit hohen Anforderungen an Datenkonsistenz

🐬 MariaDB

Ein leichter, MySQL-kompatibler Klassiker – ideal für klassische Webanwendungen und einfache Hosting-Szenarien.
Eingesetzt bei:

• WordPress & Web-Hosting

• Community-Tools mit geringerem Datenvolumen

• Nextcloud & ähnliche Dienste

Mehr über unseren MariaDB Cluster kannst Du hier finden.

Warum beide?
Weil nicht jede Datenbank alles gleich gut kann. Statt uns auf ein System festzulegen, setzen wir gezielt das ein, was für den jeweiligen Zweck am besten funktioniert.

Unsere PostgreSQL-Architektur: Hochverfügbarkeit mit Open Source

Um eine ausfallsichere Umgebung für zentrale Systeme zu schaffen, setzen wir bei PostgreSQL auf folgende Komponenten:

📌 PostgreSQL als stabile, relationale Datenbank
📌 Patroni für automatische Failover
📌 etcd als verteilter Konsensdienst
📌 HAProxy + Keepalived für redundante Zugänge
📌 Monitoring mit CheckMK

Die Architektur im Überblick

• 4 PostgreSQL-Knoten, von denen einer aktiv („Primary“) ist. Einer davon an einem anderen Standort.

• 2 HAProxy Instanzen. HAProxy ist ein sogenannter Loadbalancer – er verteilt Anfragen auf mehrere Server und sorgt dafür, dass Nutzer:innen immer mit dem richtigen Datenbankknoten verbunden werden. Wenn ein Knoten ausfällt oder gerade nicht zuständig ist, leitet HAProxy die Anfrage automatisch an den nächsten verfügbaren weiter. In Kombination mit Keepalived betreiben wir zwei HAProxy-Server mit einer gemeinsamen IP-Adresse – so bleibt der Zugang zur Datenbank auch dann verfügbar, wenn ein Loadbalancer ausfallen sollte.  

• 5 etcd-Knoten zur Koordination des Clusters
  etcd ist eine Art „Gedächtnis“ für verteilte Systeme. Es speichert, welcher Knoten aktuell der Primary ist, und hilft dabei, dass sich alle Patroni-Instanzen im Cluster abstimmen können. Man kann es sich wie ein digitales Abstimmungssystem vorstellen, das sicherstellt, dass alle denselben Stand der Dinge kennen – das ist essenziell, um sogenannte „Split-Brain“-Situationen zu vermeiden, bei denen zwei Knoten gleichzeitig glauben, sie seien zuständig.

• Patroni ist ein kleines, aber mächtiges Zusatzprogramm, das PostgreSQL „hochverfügbarkeitsfähig“ macht. Es überwacht ständig, ob der aktuelle Hauptknoten (Primary) noch erreichbar ist – und wenn nicht, wählt es automatisch einen neuen aus den Replikaten. So kann der Betrieb nahtlos weiterlaufen, auch wenn ein Server ausfällt. Patroni kümmert sich auch um die Replikation und sorgt dafür, dass alle Datenbankknoten synchron bleiben

Für Nutzer:innen und Anwendungen sieht das alles wie eine einzige Datenbank aus – selbst wenn im Hintergrund gerade ein Failover stattfindet. Das sorgt für Stabilität und Transparenz. Alles läuft auf unserer eigenen Infrastruktur im Rechenzentrum – nicht bei Hyperscalern, damit hat niemand außer Uns Zugriff auf die dort gespeicherten Daten.

Lessons Learned – oder: Was wir dabei gelernt haben

Der Aufbau war nicht trivial. Hier ein paar Dinge, die wir unterwegs gelernt haben:

🔐 TLS + HAProxy + Keycloak war trickreicher als gedacht
📉 WAL-Replikation braucht gute Konfiguration, sonst entstehen Lags
🧠 Split-Brain-Szenarien müssen mit etcd-Quorum aktiv verhindert werden
🔄 Failover-Prozesse müssen regelmäßig getestet werden, um Vertrauen zu schaffen
📊 Monitoring ist essenziell – wir setzen auf CheckMK mit spezifischen Plugins für PostgreSQL & Patroni

Warum das alles?

Weil wir Plattformen schaffen wollen, denen man vertrauen kann.
Weil digitale Souveränität mehr bedeutet als nur eine eigene Domain.
Weil wir zeigen wollen, dass Kompetenz, Transparenz und Verlässlichkeit möglich sind – auch im Non-Profit-Bereich.

Deine Unterstützung macht das möglich

Der Aufbau dieser Infrastruktur kostet Zeit, Geld und Nerven.
Und: Aktuell läuft für unsere Nutzerinnen und Nutzer noch nichts über dieses neue System – denn wir bauen es im Hintergrund solide und verantwortungsvoll auf. Die Datenbank ist eine wichtige Grundlage für alle folgenden Services. 

Wenn du möchtest, dass digitale Souveränität nicht nur ein Schlagwort bleibt, sondern Realität wird – dann unterstütze uns dabei:

💙 Spende jetzt für den Aufbau einer unabhängigen Plattform-Infrastruktur.
👉 https://4future.foundation/donations/independence-day/

Jeder Beitrag hilft. Danke für Eure bisherige Unterstützung! 

#4futureone #PostgreSQL #OpenSource #DigitaleSouveränität #Infrastruktur #Transparenz