PeerDB, ein modernes Datenmanagement-Startup und Teil des Ökosystems von ClickHouse, hat sich mit einer klaren Mission positioniert: Daten in Echtzeit aus Postgres-Datenbanken heraus zu streamen und sie somit an verschiedene Analysewerkzeuge und Anwendungen bereitzustellen. Dabei fällt vor allem ein technischer Entschluss ins Auge, der maßgeblich zum Erfolg der Plattform beiträgt: Jeder Cloud-Mandant bekommt eine eigene, private Postgres-Datenbank. Auf den ersten Blick mag das für einige veraltet oder wenig innovativ erscheinen, doch die Beweggründe hinter dieser Entscheidung sind tief verwurzelt in der angestrebten Stabilität, Sicherheit und Performance des Services. In dieser ausführlichen Betrachtung beleuchten wir die Hintergründe, Herausforderungen und Vorteile des Private-Postgres-Ansatzes bei PeerDB. Im Herzen jeder PeerDB-Implementierung befindet sich ein sogenanntes Katalogsystem.
Diese Datenbank ist ein Postgres-Cluster, das sämtliche Informationen über Datenpipelines, Benutzeranmeldeinformationen, Nutzungsstatistiken und voraggregierte Analytics enthält. Dabei ist es wichtig zu verstehen, dass PeerDB selbst keine Kundendaten speichert, sondern nur die Steuerungs- und Verwaltungsinformationen im Katalog hält. Diese klare Trennung erlaubt eine optimierte Verwaltung der Metadaten und eine dritte Dimension in der Skalierung der Dienste. PeerDB musste zu Beginn mehrere Modelle für die Mehrmandantenfähigkeit in Postgres evaluieren. Unter den Optionen standen das Teilen auf Zeilenebene (row-level multitenancy), Schema-pro-Mandant und Datenbank-pro-Mandant.
Jede dieser Alternativen brachte ihre eigenen Vor- und Nachteile mit sich. Die Entscheidung fiel letztlich auf das Modell, bei dem jeder Mandant eine eigene Datenbank in einem gemeinsamen Postgres-Server bekommt. Das Zeilenebenenmodell erschien zunächst kosteneffizient, da alle Mandanten innerhalb einer einzigen Datenbank angesiedelt wären. Allerdings führte diese gemeinschaftliche Speicherung relativ schnell zu erheblichen Einschränkungen im Bereich der Performance und Stabilität. Besonders problematisch waren gemeinsam genutzte Statistiken und die Gefahr, dass eine schlecht konstruierte Abfrage eines Mandanten die gesamte Plattform beeinträchtigen könnte.
Dies wäre in einer produktiven Umgebung mit mehreren Kunden ein nicht zu akzeptierendes Risiko gewesen. Schema-basiertes Mandantenmanagement brachte in der Theorie eine sauberere Trennung. Jeder Mandant würde seinen eigenen Namensraum erhalten, sodass Objektkollisionen grundsätzlich ausgeschlossen sind. Doch in der Praxis hä uften sich Probleme mit sogenannten Extension-Drifts, das heißt unterschiedliche Mandanten hatten unterschiedliche Erweiterungen installiert, was die Wartung erschwerte. Dazu kam das Problem der Namensraum-Aufblähung (pg_namespace bloat) und vor allem globale Locks bei Datenbankschemata, die DDL-Operationen (Data Definition Language) blockierten und damit zu Wartezeiten und Performanceeinbußen führten.
Das Modell der Datenbank-pro-Mandant bietet eine holistische Isolierung der Mandanten. Jeder Kunde erhält seine eigene logische Datenbank innerhalb einer gemeinsamen Postgres-Instanz. Diese strikte Trennung sorgt für einen klaren Blast Radius bei Problemen, wodurch Fehler oder Wartungen bei einem Mandanten keinerlei Auswirkungen auf andere Benutzer haben. Die Investition in diesen Grad der Isolation wird durch erhöhte Produktivität, Sicherheit und Performance mehr als aufgewogen. PeerDB betreibt etwa 80 bis 100 Mandantendatenbanken auf einer einzigen AWS RDS-Instanz.
Die Verteilung dieser Datenbanken auf mehrere RDS-Instanzen bietet eine bewusste Balance zwischen Wartungsaufwand und Kosteneffizienz. Eine Voll-Instanz pro Kunde wurde aus wirtschaftlichen Gründen verworfen, da dies besonders für kleinere Kunden unverhältnismäßige Ressourcen binden würde. Die logische Trennung in Kombination mit der gebündelten Hardware stellt sicher, dass Ressourcen optimal genutzt werden, ohne die Vorteile der Einzelisolierung zu verlieren. Der Katalog, der innerhalb der Mandantendatenbank liegt, ist bewusst schlank gehalten. PeerDB speichert keine Rohdaten, sondern lediglich notwendige Metadaten, Zähler für Datenbewegungen und voraggregierte Resultate, die schnelle Anfragen ermöglichen.
Die Datenmenge ist daher überschaubar: Die größten Tabellen bleiben deutlich unter 25 Gigabyte. Dieser Umstand ermöglicht PeerDB, Postgres in seiner traditionellen Rolle optimal zu nutzen und von dessen jahrzehntelanger Ausgereiftheit zu profitieren, ohne Speicher oder Performance-Probleme zu provozieren. Das Update- und Migrationsmanagement ist in der Architektur von PeerDB ebenfalls klar geregelt. Database-Schema-Änderungen werden über ein zentrales Migrations-Repository verwaltet und bei Upgrades über Kubernetes-Init-Container automatisiert gegen alle Mandantendatenbanken ausgeführt. Dabei sorgt ein Advisory Lock für Synchronisation, sodass nicht mehrere wartungsintensive Änderungen zeitgleich gestartet werden.
Dieser Prozess sichert sowohl Konsistenz als auch Stabilität während der Betriebsphase der Cloud-Lösung und trägt maßgeblich zur Wartbarkeit bei. Observability und Monitoring sind essentiell bei der Verwaltung hunderter logischer Datenbanken. Nach anfänglicher Nutzung eines bekannten kommerziellen Monitoring-Tools fiel PeerDB die Kostenexplosion auf, weshalb eine Migration zu Open-Source-Tools wie LogHouse und LightHouse erfolgte. Diese ermöglichen maßgeschneiderte Einblicke in Systemmetriken, Query-Performance sowie Fehleraufkommen, um proaktiv auf potenzielle Probleme reagieren zu können. Die Überwachung wird effizient über wenige zentrale Dashboards realisiert, wodurch der Verwaltungsaufwand überschaubar bleibt.
Erfahrungen aus dem Praxiseinsatz zeigen, dass der Ansatz mit individuellen Postgres-Datenbanken für jeden Kunden seinen Zweck perfekt erfüllt. Die Komplexität bleibt beherrschbar, da das Team über tiefgreifende Postgres-Expertise verfügt. Spezielle Herausforderungen im Query-Planer oder bei Locking-Szenarien konnten durch internes Know-how schnell gelöst werden. Zudem ist die Architektur durch den Open-Source-Charakter von PeerDB transparent nachvollziehbar, was Vertrauen und Sicherheit bei Kunden fördert. Natürlich müssen auch Kompromisse eingegangen werden.
Postgres-Verbindungen sind „fett“, sprich sie benötigen erhebliche Ressourcen. Zu Beginn gab es Probleme mit der Verfügbarkeit von Connection-Pools, da ein ungeeignetes Sizing der Serverressourcen zu Engpässen führte. Erst durch gezielte Anpassungen und Connection-Pooling-Lösungen konnte diese Herausforderung nachhaltig gelöst werden. Auch die Automatisierung bleibt eine Herausforderung: Das Handling von Hunderten von logischen Datenbanken erfordert weiterhin regelmäßige manuelle Eingriffe, etwa bei Berechtigungen, Erweiterungsupdates oder Permissions-Prüfungen. Automatisierte Systeme sind hier in Entwicklung, aber noch nicht perfekt.
Trotz dieser Herausforderungen bleibt der „boring“ Ansatz – also das „einfache“ Modell mit eigenständigen Datenbanken pro Mandant – der effizienteste Weg für PeerDB, Innovationen auf der Anwendungsebene umzusetzen. Der Fokus kann somit auf der Optimierung der Datensteuerung und der Nutzererfahrung liegen, anstatt auf der Lösung komplexer Skalierungsprobleme der Datenbankinfrastruktur. Sollte PeerDB in Zukunft weiter wachsen und die Limitationen des aktuellen Modells sichtbar werden, gibt es bewährte Fluchtwege. Sharding über mehrere Postgres-Instanzen, Replikationsmechanismen oder dedizierte Server für sehr große Kunden sind klassische Lösungen, die bereits vielfach im Enterprise-Umfeld eingesetzt werden und leicht adaptiert werden könnten. Bis dahin bietet das Modell maximale Stabilität, Transparenz und minimale Risikoübertragung zwischen Mandanten.
Zusammenfassend zeigt die Architektur und Philosophie von PeerDB, dass vermeintlich konservative Technologieentscheidungen nicht nur aus Nostalgie getroffen werden, sondern wohlüberlegte Strategien sind, um ein komplexes Problem im internationalen Cloud-Umfeld zu meistern. Die Verwendung einer privaten Postgres-Datenbank pro Kunde bringt nicht nur Leistung und Sicherheit, sondern garantiert auch eine langfristig skalierbare und wartbare Infrastruktur, die Wachstum ermöglicht ohne den Betrieb zu gefährden. So bleibt PeerDB für seine Kunden ein zuverlässiger Partner in einer schnelllebigen, datengetriebenen Welt und beweist eindrucksvoll, dass „boring infrastructure“ der Schlüssel zum Erfolg sein kann.
