DBaaS für PostgreSQL: Wie ayedo einen europäischen Anbieter in Wochen zur skalierbaren Plattform geführt hat

Database as a Service klingt auf dem Papier einfach: Kund:innen klicken sich eine PostgreSQL-Instanz, bekommen Backups, Monitoring und Hochverfügbarkeit – und das war’s. In der Realität ist DBaaS eine der anspruchsvollsten Plattformdisziplinen überhaupt. Nicht wegen PostgreSQL, sondern wegen allem, was außen herum zuverlässig funktionieren muss: Isolation, Storage, Backup-Strategien, Observability, Automatisierung, Auditierbarkeit – und das bei hunderten bis tausenden Instanzen.

In diesem Beitrag zeigen wir anhand eines anonymisierten Kundenprojekts, wie ayedo einem europäischen DBaaS-Provider geholfen hat, aus einer starken Idee ein belastbares Produkt zu machen. Der Kunde bleibt anonym. Der Ansatz ist reproduzierbar.

Die Ausgangslage war typisch für viele Teams, die aus tiefem Domain-Wissen heraus gründen: exzellente Datenbankexpertise, klares Marktverständnis, aber noch keine Plattform. Das Team wusste sehr genau, was es verkaufen wollte – eine souveräne Alternative zu AWS RDS, Azure Database oder Google Cloud SQL – hatte jedoch weder die Zeit noch die Teamgröße, um parallel eine komplette Produktionsplattform und den laufenden Datenbankbetrieb in Eigenregie aufzubauen.

Ausgangslage: Eine gute Idee reicht nicht – DBaaS braucht ein Infrastruktur-Backbone

Der Kunde ist ein junger Anbieter mit rund 25 Mitarbeitenden, davon etwa 10 im Platform Engineering. Das Ziel: vollständig verwaltete PostgreSQL-Datenbanken für europäische SaaS-Unternehmen – inklusive Self-Service-Provisionierung, Hochverfügbarkeit, Monitoring, Backups und Point-in-Time Recovery. Von Anfang an sollte das Angebot nicht wie „ein paar VMs mit Postgres" wirken, sondern wie ein professioneller Service: reproduzierbar, skalierbar, auditierbar.

Genau hier entsteht die erste harte Realität: DBaaS ist nicht „Postgres + ein bisschen Automatisierung". DBaaS bedeutet, dass der Betrieb der Datenbanken selbst die Software ist. Jede Instanz ist ein Produktbestandteil, jede Automationskante ein Verfügbarkeitsrisiko, jedes Backup ein Versprechen.

Für ein kleines Team entsteht daraus ein klassischer Zielkonflikt. Baut man zuerst das Infrastruktur-Backbone, vergehen Monate ohne Umsatz. Startet man zu schnell mit manuellen VMs, gewinnt man erste Kund:innen – zahlt später aber mit operativer Schuld: nicht standardisierte Setups, ungeplante Downtimes, Backup-Chaos, fehlende Isolation, unzureichende Observability.

Die konkreten Herausforderungen waren dabei sehr technisch, aber alle liefen auf eine Kernfrage hinaus: Wie schafft man „Cloud-Erlebnis" mit europäischer Souveränität – ohne Cloud-Hyperscaler?

Warum DBaaS im Kern ein Storage- und Automationsproblem ist

Bei DBaaS entscheidet sich alles an zwei Stellen: beim Lifecycle-Management der Datenbanken und beim Storage-Design. Das wird besonders sichtbar, wenn man skaliert.

Ein Self-Service-Anspruch bedeutet, dass Kund:innen Datenbanken erstellen, skalieren, upgraden, klonen, löschen oder Restores anstoßen können, ohne dass ein Engineer eingreifen muss. Das erfordert eine Orchestrierungsschicht, die den gesamten Datenbank-Lifecycle zuverlässig automatisiert – inklusive Failover, Replikation und Upgrades. Wer das nicht konsequent Kubernetes-nativ und deklarativ löst, endet zwangsläufig in einer Flotte von Sonderfällen.

Gleichzeitig explodiert das Backup-Thema. Bei hunderten Instanzen ist „tägliches Backup" nicht mehr ein Job, sondern eine Plattformfunktion. Point-in-Time Recovery mit WAL-Archivierung erzeugt schnell enorme Volumina. Dieses Datenwachstum muss kosteneffizient, performant und georedundant gehandhabt werden – und zwar so, dass Restores auch unter Last zuverlässig funktionieren.

Hinzu kommt Multi-Tenancy. Eine DBaaS-Plattform lebt davon, dass viele Kund:innen die gleiche Infrastruktur nutzen können. Aber sie stirbt daran, wenn Noisy Neighbors, Sicherheitslücken oder unzureichende Isolation auftreten. Isolation ist daher kein „Nice-to-have", sondern Teil des Produktversprechens.

Der Auslöser: Time-to-Market unter Seed-Finanzierung

Die Gründer hatten Seed-Finanzierung für 18 Monate. Das ist im Plattformgeschäft nicht viel. Wenn die Plattform sechs bis neun Monate Infrastruktur baut, bleibt zu wenig Zeit, um das eigentliche Produkt – API, Portal, Abrechnung, Customer Experience – zu entwickeln, zu vermarkten und zu skalieren.

Der Anspruch war daher klar: Das Infrastruktur-Backbone muss in Wochen stehen, nicht in Monaten. Gleichzeitig durfte es nicht „provisorisch" sein, weil genau diese Provisorien später die teuersten werden.

An diesem Punkt kam ayedo ins Spiel – mit einem Ansatz, der den Zielkonflikt auflöst: Wir stellen eine vollständig verwaltete, produktionsreife Plattformbasis bereit, damit sich das Team auf das differenzierende Produkt konzentrieren kann.

ayedos Ansatz: Managed Infrastruktur-Backbone als Beschleuniger – ohne Produktlogik aus der Hand zu nehmen

Wir haben die Aufgabe nicht als „Kubernetes-Setup" verstanden, sondern als Aufbau eines skalierbaren DBaaS-Backbones. Das bedeutet: Multi-Cluster-Fähigkeit, getrennte Steuerungsebene, verteiltes Storage, Observability als Plattformstandard, Backup und Recovery als Default – und alles so gestaltet, dass es hunderte Instanzen aushält.

Der Kern unseres Ansatzes bestand aus drei Prinzipien:

Erstens: Die Steuerungsebene muss unabhängig von den Workloads sein. Wenn ein Workload-Cluster Probleme hat, darf das nicht die Fähigkeit blockieren, zu deployen, zu beobachten oder zu recovern.

Zweitens: Storage muss die Plattform skalieren, nicht umgekehrt. Block-Storage für Datenbank-I/O und Object-Storage für Backup/Archivierung müssen zusammen gedacht werden, sonst explodieren Kosten oder Restores werden langsam.

Drittens: Automatisierung und Auditierbarkeit müssen in der DNA stecken. DBaaS ohne GitOps, ohne klare Deklaration und ohne nachvollziehbare Change-Historie ist im Scale nicht beherrschbar.

Infrastruktur-Architektur: Multi-Cluster von Tag eins – mit getrennter Management-Ebene

Wir haben mehrere Managed Kubernetes Cluster in zwei deutschen Regionen aufgebaut und einen weiteren Cluster an einem zweiten europäischen Standort ergänzt. Der entscheidende Punkt ist nicht „mehr Cluster", sondern Blast Radius und Produktfähigkeit. Kunden sollen Regionen wählen können. Gleichzeitig darf ein Cluster-Problem nicht die gesamte Plattform betreffen.

Zusätzlich haben wir dedizierte Management-Cluster etabliert, getrennt von den Datenbank-Workload-Clustern. In dieser Management-Ebene laufen die Steuerungs- und Plattformkomponenten: GitOps-Controller, zentraler Observability-Stack und Backup-Orchestrierung. Diese Trennung sorgt dafür, dass die Plattform steuerbar bleibt – selbst wenn ein Workload-Cluster degradiert ist. Genau das ist im Incident-Fall Gold wert: Wer seine Control Plane und seine Tooling-Ebene mit den Workloads vermischt, baut sich ein Single Point of Failure in die Organisation.

Datenbank-Orchestrierung: CloudNativePG als Herz der Plattform

DBaaS steht und fällt mit einem zuverlässigen Operator. Wir haben CloudNativePG als Kubernetes-nativen PostgreSQL-Operator eingesetzt, weil er den gesamten Lifecycle von PostgreSQL-Clustern deklarativ abbilden kann – nicht nur Provisionierung, sondern auch Failover, Replikation, Upgrades und Backup-Integration.

Statt „eine Datenbankinstanz" zu deployen, deployt die Plattform für jede Kundeninstanz einen eigenständigen PostgreSQL-Cluster mit definierter Topologie. Für Entwicklungszwecke kann das eine Single-Instance sein, für Production ein Drei-Node-HA-Cluster mit synchroner Replikation, klaren Ressourcenlimits und reproduzierbarer Konfiguration. Das Entscheidende daran: Diese Topologien sind nicht Handarbeit, sondern ein Standard, den das Produkt anbietet.

CloudNativePG sorgt außerdem dafür, dass Failover kein Runbook ist, sondern eine Plattformfunktion. Node- oder Pod-Ausfälle werden automatisch kompensiert. Replikation wird konsistent gehandhabt, und Minor-Version-Upgrades können kontrolliert automatisiert werden. Damit wird Betrieb skalierbar, weil er nicht mehr pro Instanz betreut werden muss.

Storage: Ceph als skalierbare Schicht für Performance und Kapazität

Für DBaaS ist Storage kein Detail, sondern ein zentrales Differenzierungsmerkmal. Klassischer Cloud-Block-Storage wäre in dieser Größenordnung teuer, und reine Object-Storage-Ansätze sind für Datenbank-Volumes nicht geeignet. Gleichzeitig braucht man für Backups genau die Vorteile von Object Storage: kosteneffiziente Kapazität, Skalierbarkeit, S3-Kompatibilität.

Wir haben daher Ceph als verteiltes Storage-Backend eingesetzt und bewusst zwei Storage-Charakteristiken in einem System genutzt:

Für die Datenbank-Volumes kommt Ceph RBD als replizierter, performanter Block-Storage zum Einsatz. Das liefert konsistente I/O-Performance und bleibt auch bei Node-Ausfällen stabil, weil Ceph Replikation und Rebalancing systemisch abbildet.

Für Backups und WAL-Archivierung nutzen wir Ceph RGW als S3-kompatibles Object Storage. Das ist der Schlüssel, um Backup-Volumina in den Griff zu bekommen: günstiger als Block-Storage, horizontal skalierbar und perfekt geeignet für Base-Backups und WAL-Segmente.

Diese Trennung – Performance-Storage für Datenbanken, Kapazitäts-Storage für Backups – ist eine der wichtigsten Plattformentscheidungen in diesem Projekt. Sie ermöglicht Kostenkontrolle, ohne an Zuverlässigkeit oder Restore-Fähigkeit zu sparen.

Backup und Point-in-Time Recovery: PITR als Produktversprechen, nicht als Option

Bei DBaaS ist „Backup vorhanden" kein Qualitätsmerkmal. Entscheidend ist: Kann ich zuverlässig, schnell und reproduzierbar wiederherstellen?

Wir haben Point-in-Time Recovery über kontinuierliche WAL-Archivierung in Kombination mit regelmäßigen Base-Backups umgesetzt. Dadurch ist ein Restore auf beliebige Zeitpunkte innerhalb der Retention möglich – bis auf Sekundenebene. Gleichzeitig wurden Backups automatisiert georedundant in eine zweite Region repliziert, um regionale Ausfälle abfedern zu können.

Wichtig war uns außerdem: Backup-Integrität darf nicht geschätzt werden. Deshalb wurden automatisierte Restore-Tests etabliert, die regelmäßig die Wiederherstellbarkeit verifizieren. In der Praxis ist das einer der häufigsten Gründe, warum Plattformen im Ernstfall scheitern: Backups existieren, aber niemand hat Restore je ernsthaft geprobt.

Observability: Mandantenfähig, skalierbar, kundenfähig

Ein DBaaS-Anbieter braucht doppelte Observability. Einerseits muss das interne Operations-Team den Zustand der gesamten Plattform sehen: Cluster, Storage-Kapazitäten, Error Rates, Replikationszustände, Trends. Andererseits erwarten Kund:innen Self-Service-Zugriff auf ihre Metriken und Logs – ohne dass dadurch Einblicke in andere Mandanten möglich sind.

Wir haben dafür VictoriaMetrics und VictoriaLogs als zentralen Monitoring- und Logging-Stack integriert. Der Plattformvorteil liegt hier in der nativen Multi-Tenancy-Fähigkeit: Metriken können mandantengetrennt gespeichert und abgefragt werden, ohne separate Monitoring-Stacks pro Kunde aufbauen zu müssen. Das reduziert Komplexität massiv und macht „Kunden-Dashboards" zu einer skalierbaren Funktion, nicht zu einer Dauerbaustelle.

Grafana dient als Oberfläche – sowohl für interne, plattformweite Dashboards als auch für mandantenfähige Kundensichten. So kann das Support-Team auf einen Blick erkennen, ob etwa Replication Lag steigt, Connection Pools an Grenzen stoßen oder Storage-Druck entsteht. Kund:innen sehen genau die Signale, die sie brauchen, um ihre Anwendung zu verstehen – ohne Zugriff auf andere Daten.

Isolation: Multi-Tenancy mit harter Trennung auf Netzwerk- und Ressourcenebene

Multi-Tenancy in DBaaS scheitert häufig nicht am Datenbankbetrieb, sondern an Noisy Neighbors und unzureichender Isolation. Wenn ein Kunde mit einer „ungünstigen" Query-Last die Nachbarn beeinflusst, ist das nicht nur ein Performance-Problem, sondern ein Vertrauensbruch.

Wir haben deshalb Netzwerk-Isolation über Cilium umgesetzt und Network Policies so etabliert, dass jede Datenbankinstanz nur über explizit freigegebene Pfade erreichbar ist. Auf Compute-Ebene werden Ressourcen pro Instanz klar begrenzt und kontrolliert, sodass „falsche" Workloads nicht unbemerkt die Plattform destabilisieren. Auf Storage-Seite sorgt die Volume-Trennung dafür, dass Mandanten nicht über gemeinsame Volumes miteinander verwoben sind. Zusammen entsteht ein Isolationsmodell, das sowohl sicherheits- als auch performanceseitig belastbar ist.

GitOps als Provisionierungsmechanismus: Jede DB ein Commit, jede Änderung auditierbar

Ein zentraler Bestandteil des Produktes war Self-Service-Provisionierung. Unsere Plattformarchitektur musste daher den Übergang ermöglichen: Der Kunde baut API und Portal – und die Infrastruktur setzt die gewünschte Realität um.

Genau dafür ist GitOps ideal. Wenn über die DBaaS-API eine neue Instanz erstellt wird, entsteht daraus deklarativ ein Manifest, das ins GitOps-Repository geschrieben wird. ArgoCD erkennt die Änderung und reconciliert den Zustand im Zielcluster. Damit wird Provisionierung nachvollziehbar, versioniert und auditierbar.

Das ist mehr als eine Deployment-Technik. Es ist ein Governance-Modell. In DBaaS ist Auditierbarkeit kein Nice-to-have: Wer wann welche Parameter geändert hat, welche Topologie ausgerollt wurde, wann Upgrades passiert sind – all das muss nachvollziehbar sein, gerade bei regulierten Kund:innen.

Identity und Zugriffssteuerung: Authentik als Basis für Rollen und Mandanten

Damit Kund:innen im Portal, in Grafana oder in Plattformfunktionen wirklich nur ihre Ressourcen sehen, braucht es ein konsistentes Identity- und Rollenmodell. Wir haben Authentik als zentrale Identity-Schicht integriert, um SSO, Rollen und Zugriffskontrolle sauber zu verwalten. Damit wird Mandantentrennung nicht nur technisch erzwungen, sondern auch organisatorisch und auditierbar abgebildet.

Ergebnis: Von Seed-Idee zur produktionsreifen DBaaS-Plattform in vier Monaten

Der messbare Effekt war Time-to-Market. Der Infrastruktur-Backbone stand innerhalb von sechs Wochen. Dadurch konnte das Team seine Energie auf die Produktlogik konzentrieren: DBaaS-API, Kundenportal, Automationslogik und go-to-market. Vier Monate nach Start bediente der Anbieter die ersten zahlenden Kund:innen.

Die Plattform skaliert heute auf über 800 Datenbank-Instanzen – von kleinen Development-Setups bis zu Multi-Terabyte-HA-Clustern. Provisionierung dauert unter einer Minute, Failover läuft automatisiert im Sekundenbereich, und Point-in-Time Recovery ist nicht nur vorhanden, sondern getestet.

Storage-Kosten bleiben kontrollierbar, weil Performance- und Kapazitätsanforderungen sauber getrennt sind. Backup-Daten werden georedundant repliziert, ohne dass das Team manuell eingreifen muss. Monitoring und Logs sind mandantenfähig zugänglich, ohne pro Kunde individuelle Monitoring-Setups zu bauen.

Und vielleicht am wichtigsten: Das Team musste nicht auf 30 Plattform-Engineers wachsen, nur um Infrastruktur zu betreiben. Durch den Managed-Backbone konnten die vorhandenen Engineers am Produkt arbeiten, statt Cluster, Storage und Observability als Dauerprojekt zu managen.

Warum dieser Ansatz funktioniert: DBaaS gewinnt nicht durch Features, sondern durch Betriebssystematik

DBaaS ist ein Vertrauensprodukt. Kund:innen kaufen keine Datenbank, sie kaufen das Versprechen, dass diese Datenbank morgen früh genauso zuverlässig läuft wie heute – inklusive Recoverability, Isolation, Transparenz und klaren SLAs.

Genau darum funktioniert der Ansatz, wenn er drei Dinge vereint:

Erstens: Eine Plattformbasis, die hochverfügbar und skalierbar ist, bevor die erste Kundendatenbank produktiv geht. Zweitens: Eine Orchestrierungsschicht, die Datenbankbetrieb automatisiert – ohne Eigenentwicklung eines Operators. Drittens: Storage- und Backup-Design, das nicht nachträglich „dazukommt", sondern PITR, Georedundanz und Kostenkontrolle von Anfang an ermöglicht.

Das Ergebnis ist eine Plattform, die wie Cloud wirkt – aber souverän europäisch bleibt.

Call to Action

Wenn ihr ein DBaaS-Angebot plant oder bereits Datenbanken für Kund:innen betreibt und merkt, dass manuelle VM-Setups euch langfristig ausbremsen, dann ist der nächste Schritt kein „Tool-Wechsel". Es ist der Aufbau eines Infrastruktur-Backbones, der Automatisierung, Isolation, Observability und Recovery als Default liefert.

ayedo stellt dafür die Basis bereit: Managed Kubernetes in mehreren Regionen, bewährte Plattformkomponenten für Storage, Backup, GitOps und Monitoring – und das so, dass euer Team am Produkt arbeiten kann, statt Infrastruktur als Dauerprojekt zu betreiben.

Wenn ihr eine souveräne Alternative zu RDS bauen wollt – lasst uns sprechen.