Schlüsselpunkte
- Ein DBA (Database Administrator) sorgt mit tiefem operativem Fachwissen dafür, dass Datenbanken stabil und sicher laufen.
- Ein DBRE (Database Reliability Engineer) erweitert die klassischen DBA-Aufgaben um Automatisierung und DevOps-Praktiken, um manuellen Aufwand zu reduzieren und die Zuverlässigkeit von Datenbanken im großen Maßstab zu verbessern.
- Ein SRE (Site Reliability Engineer) überträgt Prinzipien der Softwareentwicklung auf das gesamte Produktivsystem und misst und steuert die Systemzuverlässigkeit über SLOs (Service Level Objectives) und Fehlerbudgets.
- Wenn Unternehmen wachsen, entstehen durch unklare Grenzen zwischen diesen drei Rollen Verantwortungslücken, die die Reaktion auf Vorfälle verlangsamen.
- Der richtige Zeitpunkt für DBRE- oder SRE-Rollen ist erreicht, wenn Deployment-Frequenz, Verfügbarkeitszusagen oder Infrastrukturkomplexität über das hinauswachsen, was reaktiver, manueller Betrieb leisten kann.
Dieser Artikel zeigt die grundlegenden Unterschiede zwischen den Rollen DBA, DBRE und SRE. Der Leitfaden richtet sich in erster Linie an alle, die ihre beruflichen Optionen abwägen. Er eignet sich aber ebenso für erfahrene IT-Profis, die moderne IT-Begriffe noch einmal auffrischen möchten. Erwähnenswert ist außerdem: Einige Aufgaben der Rollen überschneiden sich durchaus, trotzdem ist jede Rolle in ihrer Funktion, ihrer Bedeutung und ihrem Beitrag im Unternehmen einzigartig.
Kurzüberblick: DBA, DBRE und SRE im Vergleich
| DBA | DBRE | SRE | |
| Steht für | Database Administrator | Database Reliability Engineer | Site Reliability Engineer |
| Schwerpunkt | Stabilität und Integrität der Datenbank | Datenbank-Automatisierung und Zuverlässigkeit | Zuverlässigkeit des Gesamtsystems |
| Umfang | Datenbank | Datenbank + zugehöriges Ökosystem | Gesamter Produktiv-Stack |
| Denkweise | Operativ („reparieren“) | Präventiv („automatisieren“) | Systemisch („konstruieren“) |
| Zentrale Fähigkeiten | Query-Optimierung, Datenmodellierung, Backup/Wiederherstellung | Infrastructure as Code, CI/CD, Observability-Tools | Verteilte Systeme, Koordination bei Vorfällen, Kapazitätsplanung |
| Arbeitet zusammen mit | Ops-Teams, Sicherheitsteams | Dev-Squads, DevOps-Teams | Allen Engineering-Teams |
| Erfolgsmaßstab | Verfügbarkeit, Datenintegrität | SLOs, weniger manueller Aufwand, Automatisierungsgrad | Fehlerbudgets, systemweite SLOs, Häufigkeit von Vorfällen |
| Typische Tools | pgAdmin, Oracle Enterprise Manager, SQL Server Management Studio | Terraform, Flyway, Liquibase, Prometheus | PagerDuty, Grafana, eigene Automatisierungs-Frameworks |
Die Aufgaben eines DBA
Ein Database Administrator (DBA) hält Ihre Datenbank am Laufen und sorgt für ihren guten Zustand. DBAs gelten oft als erste Verteidigungslinie: Sie stellen sicher, dass die Datenbank sicher bleibt und wieder online geht, wenn etwas schiefläuft. Ihre Arbeit dreht sich um betriebliche Stabilität, und sie sind verantwortlich für:
- Installation und Konfiguration der Datenbank
- Die korrekte Einrichtung der Engine für die jeweilige Workload
- Verwaltung von Daten-Backup und Wiederherstellung (einschließlich der Entscheidung für die beste Software für Daten-Backup und Wiederherstellung)
- Analyse langsamer Queries
- Identifizierung von Engpässen
- Optimierung von Indizes
- Durchsetzung von Sicherheits- und Zugriffskontrollen
- Regelmäßiges Patching und Upgrades
Diese Aufgabe hat sich nicht verändert, die Methoden sind jedoch komplexer geworden, um modernen IT-Anforderungen gerecht zu werden. Konkret versteht ein versierter DBA die Interna von Systemen wie MySQL, PostgreSQL oder SQL Server sehr genau, deutlich tiefer als „durchschnittliche“ Engineers. DBAs wissen, wie Ausführungspläne für Queries funktionieren, wie Storage-Engines Transaktionen verarbeiten und warum eine bestimmte Index-Strategie einer Workload nützt, einer anderen aber schadet.
Im Kern stellt ein DBA sicher, dass ein Datenbankserver im Hinblick auf Stabilität, Performance und Zuverlässigkeit richtig konfiguriert ist. Entsprechend zählen für DBAs vor allem Konsistenz und Verfügbarkeit. Geht etwas kaputt, repariert es der DBA.
Allerdings kann dieses reaktive Break/Fix-Modell zum betrieblichen Engpass werden, besonders in komplexeren IT-Architekturen.
Die Aufgaben eines DBRE
Ein Database Reliability Engineer (DBRE) setzt genau dort an, wo ein „klassischer“ DBA an Grenzen stößt. DBREs nehmen die Grundlage, die ein DBA geschaffen hat, und ergänzen sie um Automatisierung, Skalierbarkeit und moderne DevOps-Praktiken.
(Bevor wir fortfahren, ein wichtiger Hinweis: Die Existenz von DBRE-Rollen schmälert die Bedeutung von DBA-Rollen keineswegs. Der Unterschied ähnelt dem zwischen Hausärzt:innen und Fachärzt:innen. Nur weil es Neurolog:innen gibt, müssen Sie bei einem kleinen Kratzer an der Stirn nicht gleich dorthin.)
DBREs sind darauf trainiert, sich zu fragen: „Wie kann ich das automatisieren, damit dieses Problem nie wieder auftritt?“ Sie übertragen die Prinzipien des Site Reliability Engineering (erstmals von Google formalisiert) gezielt auf die Datenbankebene. Während ein DBA Probleme in der Regel manuell löst, entwickelt ein DBRE den Instinkt, Systeme durch präventive Maßnahmen zu verbessern, meist per Automatisierung. Jeder Vorfall wird zur Gelegenheit, das System zu verbessern. Jede sich wiederholende Aufgabe ist ein Kandidat für Automatisierung. Dieser Wandel der Denkweise, vom Administrator zum Engineer, ist das prägende Merkmal der DBRE-Rolle.
In der Praxis übernimmt ein DBRE folgende Aufgaben:
- Automatisierung der Datenbank-Bereitstellung
- Integration von Schema-Änderungen in CI/CD-Pipelines
- Aufbau von Self-Healing- und Failover-Mechanismen
- Überwachung von Service Level Objectives (SLOs) für die Datenbank-Performance
- Reduzierung manueller Routinearbeit, des sogenannten „Toil“ (ein Begriff aus der SRE-Kultur für all die repetitive, manuelle Betriebsarbeit, die sich automatisieren ließe und sollte)
Eine weitere wichtige Neuerung durch DBREs ist die enge Verzahnung mit den Entwicklungsteams. Statt auf Tickets zu warten, nehmen DBREs an Planungsmeetings teil, prüfen Code für Datenzugriffe und arbeiten bei Architekturentscheidungen für neue Features mit. Die Verantwortung für die Datenbank-Performance liegt damit nicht mehr allein beim DBA, sondern wird zwischen Entwicklung und Betrieb geteilt. Genau diese geteilte Verantwortung erlaubt es Teams, schneller zu arbeiten, ohne Zuverlässigkeit zu opfern.
Die Aufgaben eines SRE
Ein Site Reliability Engineer (SRE) wendet Prinzipien der Softwareentwicklung an, um ganze Produktivsysteme zuverlässig und messbar zu halten, nicht nur Datenbanken. Wie im vorherigen Abschnitt erwähnt, entstand die SRE-Rolle zuerst bei Google und wurde über die frei verfügbaren SRE-Bücher bekannt. Die Grundidee ist recht simpel: Betriebsprobleme als Softwareentwicklungsprobleme behandeln und sie mit Code, Automatisierung und Daten lösen statt mit manueller Arbeit.
Ein SRE ist in der Regel verantwortlich für:
- Die Definition von SLOs über den gesamten Anwendungs-Stack hinweg.
- Den Aufbau von Automatisierungs-Frameworks, die manuelle Arbeit in Infrastruktur, Deployments und bei der Reaktion auf Vorfälle reduzieren.
- Die Überwachung der End-to-End-Service-Gesundheit anhand von Metriken, die die tatsächliche Benutzererfahrung abbilden.
- Die Leitung von Post-Mortem-Reviews nach Vorfällen, die auf systemische Verbesserungen statt auf Schuldzuweisungen abzielen.
- Architekturempfehlungen, die die Widerstandsfähigkeit des Systems erhöhen.
Darin liegt der zentrale Unterschied zwischen den Rollen: Das Wissen eines DBRE geht bei Datenbank-Interna in die Tiefe, das eines SRE in die Breite über verteilte Systeme hinweg. Das bedeutet auch: SREs verwalten zwar die verschiedenen Ressourcen, auf denen alles läuft (dazu können auch Datenbankserver gehören), erreichen auf Datenbankseite aber nicht die Tiefe eines DBRE. Ein SRE versteht beispielsweise genug von Query-Performance, um bei der Fehlersuche Kontext zu liefern. Einen komplexen Ausführungsplan zu analysieren oder eine Replikationsstrategie zu entwerfen, gehört jedoch nicht dazu. Das ist DBRE-Terrain.
Der SRE bringt außerdem zwei der wichtigsten Konzepte moderner Zuverlässigkeitsarbeit mit:
- SLO: Definiert ein messbares Zuverlässigkeitsziel (zum Beispiel: „99,9 % der Login-Queries müssen über einen Zeitraum von 28 Tagen innerhalb von 200 ms abgeschlossen sein.“)
- Fehlerbudget: Das rechnerische Gegenstück (zum Beispiel: „die 0,1 % der Zeit, in denen das System dieses Ziel verfehlen darf.“)
Ist das Fehlerbudget gut gefüllt, haben Teams Spielraum, neue Features zügig auszuliefern. Ist es nahezu aufgebraucht, verschiebt sich die Priorität des Teams automatisiert hin zur Stabilität. Dieses Modell ersetzt die endlose Debatte zwischen „Wir müssen schnell sein“ und „Wir müssen stabil sein“ durch eine einzige, gemeinsame, datenbasierte Kennzahl.
DBA, DBRE und SRE im direkten Vergleich
Sie sehen, wie sich diese drei Rollen überschneiden können. Eine Gegenüberstellung hilft jedoch, die konkreten Unterschiede herauszuarbeiten.
Die Expertise des DBA ist konzentriert. DBAs kennen bestimmte Datenbank-Engines bis ins Detail und haben jahrelange Erfahrung in der Planung von Backup und Wiederherstellung. Sie sind die erste Anlaufstelle, wenn auf der Datenebene etwas schiefgeht: Stellen Sie eine Anfrage rund um die Datenbank, antwortet in der Regel der DBA. Ihre Denkweise ist von Grund auf operativ: Die Datenbank stabil und verfügbar halten.
Der DBRE baut auf dieser Grundlage auf und ergänzt sie um eine Engineering-Denkweise. Solides Datenbankwissen bleibt nötig, kommt aber zusammen mit Automatisierung und einem fundierten Verständnis von Zuverlässigkeitsmetriken und Performance-Baselines. Die Denkweise ist dagegen präventiv: Erkennen, was schiefgehen könnte, und es per Automatisierung aus der Welt schaffen.
SREs arbeiten auf der breitesten Ebene. Sie müssen verteilte Systeme verstehen, die Reaktion auf Vorfälle über mehrere Teams hinweg koordinieren, Kapazitäten für großen Maßstab planen und Automatisierung aufbauen, die plattformübergreifend funktioniert, nicht nur für Datenbanken. Ihre Denkweise ist damit systemisch: Wie verhält sich der gesamte Service unter realen Bedingungen, und welche Engineering-Investitionen machen ihn widerstandsfähiger?
Wenn Sie über einen Berufswechsel nachdenken, sollten Sie wissen: Diese Rollen verlangen zunehmend breitere technische und operative Fähigkeiten. Wer als DBA in eine DBRE-Rolle wechseln möchte, muss in Automatisierung, Infrastructure as Code, Überwachungstools und CI/CD-Integration investieren. Ein DBRE auf dem Weg zur SRE-Arbeit muss sein Systemdenken über die Datenbank hinaus erweitern und stärkere plattformübergreifende Engineering-Fähigkeiten aufbauen. Die Entwicklung verläuft natürlich, doch jeder Schritt erfordert eine bewusste Erweiterung sowohl der technischen Fähigkeiten als auch der Perspektive auf das Unternehmen.
So sorgen Sie für klare Rollenabgrenzung bei DBA, DBRE und SRE
Es versteht sich von selbst, dass ein klares Verständnis dieser Rollen entscheidend ist, um Unklarheiten im Unternehmen zu vermeiden. Für eine saubere Rollenabgrenzung sollten Sie vorab einige Fragen beantworten, etwa:
- Wer verantwortet Vorfälle in Produktivdatenbanken: der DBA, der DBRE oder der SRE?
- Wer ist für die Definition und Pflege der Datenbank-SLOs zuständig?
- Wer verantwortet die Automatisierung von Schema-Migrationen, Failover und Bereitstellung?
- Wie schlagen sich Zuverlässigkeitsziele in den Leistungszielen der einzelnen Teams nieder?
Klare Antworten darauf ermöglichen es Ihrem Team, bei Vorfällen sofort und eindeutig zu reagieren und menschliche Fehler zu vermeiden.
Dennoch ist es in kleinen Unternehmen völlig legitim, dass eine Person DBA-, DBRE- und SRE-Aufgaben in sich vereint. Entscheidend ist, dass die Verantwortlichkeiten auch in einem solchen Umfeld klar definiert bleiben. Mit dem Wachstum eines Unternehmens gewinnt Spezialisierung an Wert, und die Kosten von Unklarheit steigen mit.
Der richtige Zeitpunkt für DBRE- oder SRE-Rollen im Unternehmen
Nicht jedes Unternehmen braucht alle drei Rollen vom ersten Tag an, und es gibt keine allgemeingültige Regel dafür, wann man sie formalisieren sollte. Es gibt jedoch klare Signale dafür, dass das bestehende Modell an seine Grenzen stößt.
- Häufige Vorfälle in der Produktion: Das ist das offensichtlichste Signal. Wenn Ihr Team regelmäßig Datenbankprobleme löschen muss, ist das ein deutlicher Hinweis darauf, dass reaktive DBA-Arbeit allein nicht mehr mit Ihrer Umgebung mitwächst.
- Schnelle Deployment-Zyklen: Wenn Ihre Entwicklungsteams mehrmals täglich deployen, Ihr Prozess für Datenbankänderungen aber weiterhin eine manuelle Übergabe erfordert, haben Sie einen Engpass geschaffen.
- Wachsende Automatisierungsanforderungen: Wenn Ihr Unternehmen höhere Verfügbarkeitsanforderungen und häufige Deployments hat, ist es womöglich Zeit, SRE-Verantwortlichkeiten oder -Rollen zu formalisieren.
Als Faustregel gilt: Wenn Ihr Team Fragen wie „Welche manuellen Aufgaben haben Sie diese Woche erledigt, die sich skripten ließen?“ oder „Wie viel Zeit ging für manuelle Schema-Deployments drauf?“ nicht beantworten kann, ist es vermutlich Zeit, sich je nach Bedarf nach einem DBRE oder SRE umzusehen.
Datenbankbetrieb: Rollen richtig einordnen
DBAs, DBREs und SREs werden häufig verwechselt, dabei stehen sie für völlig unterschiedliche, aber einander ergänzende Rollen einer sich weiterentwickelnden Zuverlässigkeitspraxis. Wer seine beruflichen Optionen abwägt, sollte überlegen, welche Bereiche ihn am meisten interessieren, und Fähigkeiten und Erfahrung darauf ausrichten. IT-Verantwortliche sollten klar definieren, was jede Rolle im eigenen Unternehmen konkret umfasst. Wenn alle wissen, wer wofür zuständig ist, werden Vorfälle schneller gelöst, Automatisierung wird ohne Doppelarbeit aufgebaut, und Zuverlässigkeitsziele bleiben nicht länger Wunschdenken, sondern werden messbar.
Verwandte Themen:
