2027: Verwaltete Datenbank oder Eigenbetrieb? Gesamtkosten nach Workload berechnen

Wenn die Datenbanklast dauerhaft und gut messbar ist, das Team Bereitschaft und Wiederherstellung übernehmen kann und Backup sowie Redundanz eingerechnet sind, sollte es den Eigenbetrieb prüfen. Andernfalls ist eine verwaltete Datenbank meist die bessere Wahl. Eine selbst gemietete physische Maschine liefert weder automatisch Hochverfügbarkeit noch ein Backup.

Dieser Vergleich richtet sich an DBA, Backend- und Dateningenieure, die PostgreSQL oder MySQL aus einem verwalteten Dienst migrieren oder das Datenbankbudget für 2027 planen. Besonders relevant ist er, wenn die Rechnung steigt, aber noch unklar ist, welche Betriebsaufgaben nach einer Migration beim eigenen Team liegen.

Zuletzt aktualisiert am 23.10.2026. Abgeglichen mit den offiziellen Preis- und Produktinformationen in den verlinkten Quellen sowie den für NodeKVM bereitgestellten Produktangaben.

Erst dieselbe Leistung vergleichen, dann die Kosten

Ein belastbarer Kostenvergleich verwaltete Datenbank versus Eigenbetrieb beginnt nicht mit dem Preis einer Instanz. Beide Optionen müssen dieselbe Arbeit erledigen und dieselben Anforderungen erfüllen. Sonst vergleichen Sie unterschiedliche Leistungen: etwa einen verwalteten Datenbankdienst mit automatisierten Sicherungen gegen einen Server, für den Backup, Überwachung und Wiederherstellung noch nicht eingeplant sind.

Legen Sie vor dem Rechnen fest:

• Welche Datenbank, Version und Arbeitslast werden verglichen?
• Welche Verfügbarkeit und welche maximale Unterbrechung sind erforderlich?
• Wie lange müssen Daten und Backups aufbewahrt werden?
• Welcher Abrechnungszeitraum wird angesetzt?
• Wer übernimmt Patches, Monitoring, Störungsbehebung und Wiederherstellung?

Bei der verwalteten Variante besteht die Rechnung nicht zwingend nur aus der Datenbankinstanz. Je nach Dienst und Auswahl können unter anderem Rechenleistung, Speicher, Sicherungen, Datenübertragung und Hochverfügbarkeit in die Kosten einfließen. Die offiziellen Preisangaben für verwaltete PostgreSQL-Datenbanken und die Preisübersicht für einen verwalteten SQL-Dienst zeigen, welche Optionen beim jeweiligen Angebot in die Kalkulation eingehen. Prüfen Sie die aktuell angezeigten Bedingungen; übernehmen Sie keine früher erstellten Preisbeispiele.

Ein offizieller Preisrechner für Cloud-Dienste kann Varianten abbilden. Das Ergebnis ist jedoch nur so brauchbar wie die eingegebenen Annahmen. Stimmen Speicherbedarf, Sicherungsdauer oder Verfügbarkeitsoption nicht mit dem tatsächlichen Betrieb überein, ist der berechnete Betrag kein fairer Vergleichswert.

Für den Eigenbetrieb gehören mindestens Servermiete, externe Datensicherung, Speicherreserven und der Zeitaufwand für Betrieb und Störungen in die Rechnung. Ein Serverpreis allein ist deshalb kein Gesamtpreis.

Kleine oder schwankende Last: Flexibilität gegen Betriebsarbeit abwägen

Bei einer kleinen, saisonalen oder stark schwankenden Datenbank kann der verwaltete Dienst trotz höherer Rechnung passend sein. Der Wert liegt dann nicht allein in der Rechenleistung. Ein Team kann Kapazität anpassen, statt eine physische Maschine dauerhaft für Spitzen vorzuhalten. Umgekehrt können Mindestressourcen und gewählte Optionen auch in ruhigen Phasen Kosten verursachen.

Die verwaltete Datenbank ist zu teuer – wann lohnt sich Eigenbetrieb?
Eigenbetrieb lohnt sich nicht allein deshalb, weil die Monatsrechnung hoch aussieht. Er wird prüfenswert, wenn die Last über längere Zeit stabil ist, der benötigte Ressourcenbedarf bekannt ist und das Team die zusätzlichen Betriebsaufgaben verantworten kann. Rechnen Sie zuerst den Jahresbedarf einschließlich Backup, Redundanz und Arbeitszeit. Wenn der Vorteil nur entsteht, weil diese Posten fehlen, ist er nicht belastbar.

Vergleichen Sie nicht nur einen besonders ruhigen Monat mit einem dauerhaften Serverpreis. Erfassen Sie den Verlauf über den tatsächlichen Budget- und Lastzyklus des Teams. Notieren Sie dabei Spitzen, regelmäßige Batch-Läufe, Wachstum und Zeiten mit niedriger Auslastung. Eine einzelne Monatsrechnung bildet schwankende Nutzung nicht zuverlässig ab.

Der zweite Prüfpunkt ist die Zuständigkeit. Ein verwalteter Dienst nimmt dem Team bestimmte Aufgaben ab, aber nicht automatisch jede Verantwortung für Datenqualität, Zugriffsrechte oder die Anwendungslogik. Beim Eigenbetrieb kommen mindestens Planung und Durchführung von Betriebssystem- und Datenbankupdates, Überwachung, Kapazitätsprüfung, Backupkontrolle und Störungsbehebung hinzu. Kleine Teams sollten außerdem festlegen, wer bei Abwesenheit reagieren kann.

Die offiziellen Hinweise zur Kostenoptimierung verwalteter PostgreSQL-Datenbanken helfen, unnötige Ressourcen oder ungeeignete Einstellungen zu erkennen. Prüfen Sie solche Möglichkeiten vor einem Umzug: Eine Anpassung der bestehenden Nutzung kann wirtschaftlicher sein als ein vollständiger Wechsel des Betriebsmodells.

Stabile Produktionslast: Ressourcen aus Messwerten ableiten

Bei einer stabilen Produktionsdatenbank lässt sich der Eigenbetrieb sinnvoller kalkulieren, sofern die nötigen Messwerte vorliegen. Die Datenbankgröße allein genügt nicht zur Auswahl eines Servers. Sie sagt nicht, wie viel Arbeitsspeicher für den Puffer benötigt wird, wie stark Schreibvorgänge die Speicherleistung belasten oder welche Reserven für Wachstum und Wartung erforderlich sind.

Erheben Sie für den Vergleich die tatsächlich beobachtete CPU-Auslastung, den Arbeitsspeicherbedarf, das Datenwachstum, die Lese- und Schreibmuster sowie den Speicherbedarf von Protokollen. Erfassen Sie Lastspitzen getrennt vom Durchschnitt. Berücksichtigen Sie außerdem, welche Dienste auf derselben Maschine laufen sollen. Werden Datenbank, Monitoring, Backupsoftware oder andere Anwendungen gemeinsam betrieben, teilen sie Ressourcen.

Welche Kosten gehören bei einer selbst betriebenen PostgreSQL-Datenbank in die Rechnung?
Neben dem Serverpreis gehören externer Backup-Speicher, gegebenenfalls eine zweite Datenbank für Replikation, Netzwerkbedarf, Überwachung und der Arbeitsaufwand für Updates, Tests und Störungen dazu. Für PostgreSQL sind außerdem Archivierung und Wiederherstellung einzuplanen. Die Dokumentation zur kontinuierlichen Archivierung und Point-in-Time-Recovery beschreibt, welche Rolle Archivdateien für die Wiederherstellung spielen. Das Archiv muss jedoch auch tatsächlich erreichbar, vollständig und für den vorgesehenen Wiederherstellungsfall verwendbar sein.

Bei NodeKVM nennt die bereitgestellte Produktkonfiguration einen AMD EPYC 7543P mit 32 Kernen und 64 Threads. Für Arbeitsspeicher sind 128 GB oder 256 GB DDR4-3200 ECC RDIMM vorgesehen; als Laufwerke sind zwei direkt angeschlossene NVMe-SSDs mit je 1 TB genannt. Die Bandbreitenoptionen sind 250 Mbps, 1 Gbps oder 2 Gbps, jeweils ohne Traffic-Limit. Diese Angaben sind Konfigurationsdaten, keine Empfehlung für eine bestimmte Datenbankgröße oder ein Leistungsversprechen. Prüfen Sie die aktuelle Verfügbarkeit und die Preise auf der NodeKVM-Produkt- und Preisseite, bevor Sie Zahlen in Ihr Budget übernehmen.

Zur Abschätzung des Datenbankservers gehört auch die Frage, welche Teile der Speicherkapazität für aktive Daten, Protokolle, temporäre Dateien und Sicherungen vorgesehen sind. Eine zweite lokale NVMe kann Datenbestand oder Redundanz unterstützen, ersetzt aber keine externe Sicherung. Die Laufwerke sind direkt angeschlossen; eine Hardware-RAID-Konfiguration ist nicht angegeben. Wer Redundanz auf dem Server benötigt, muss sie selbst planen, zum Beispiel über Software-RAID oder Datenbankreplikation.

Hohe Schreiblast und lange Aufbewahrung: Speicher und Wiederherstellung mitrechnen

Bei hoher Schreiblast oder langen Aufbewahrungsfristen wird die Speicherplanung schnell zu einem wesentlichen Kostentreiber. Trennen Sie dabei drei Fragen: Wie viel Platz brauchen die aktiven Daten? Welche Protokolle und Zwischenstände werden für den laufenden Betrieb benötigt? Welche Sicherungen müssen außerhalb der Datenbankmaschine verfügbar bleiben?

Setzen Sie nicht die gesamte Plattenkapazität mit nutzbarer Datenbankkapazität gleich. Redundanz reduziert den Platz für Nutzdaten; Protokolle und Wachstum benötigen zusätzlichen Spielraum. Backupdaten auf demselben Server helfen zudem nicht gegen den Ausfall oder Verlust dieser Maschine. Der passende Plan hängt davon ab, welche Wiederherstellungspunkte benötigt werden und wie lange ein Ausfall hinnehmbar ist.

Wie stark erhöhen Backup und Hochverfügbarkeit die Eigenbetriebskosten?
Das lässt sich ohne Aufbewahrungsregeln, Änderungsrate, Speicherbedarf und gewünschtes Wiederherstellungsverhalten nicht seriös pauschal beziffern. Erfassen Sie die Größe der Sicherungsdaten, die Häufigkeit der Sicherungen, die Aufbewahrungsdauer und den Speicherort außerhalb des Servers. Für Hochverfügbarkeit kommen je nach Architektur zusätzliche Ressourcen und laufende Prüfungen hinzu. Die Kosten steigen nicht nur durch weitere Hardware oder Speicher, sondern auch durch Einrichtung, Überwachung und Tests.

Ein Software-RAID kann vor bestimmten Laufwerksausfällen schützen, ist aber keine Sicherung gegen versehentliches Löschen, kompromittierte Zugangsdaten oder den Verlust des gesamten Servers. Replikation verbessert unter passenden Bedingungen die Verfügbarkeit, kann jedoch Fehler oder Löschungen ebenfalls auf ein Replikat übertragen. Legen Sie deshalb fest, welche Schutzmaßnahme welches Risiko abdeckt. Die Dokumentation zur Verfügbarkeit eines verwalteten Datenbankdienstes beschreibt dessen Verfügbarkeitsoptionen; vergleichen Sie diese mit einer tatsächlich geplanten Eigenbetriebsarchitektur, nicht mit einer einzelnen Maschine.

Für jedes Szenario sind mindestens ein externer Backup-Speicher und eine regelmäßige Wiederherstellungsprobe zu berücksichtigen. Ein vorhandenes Backup ist noch kein Nachweis, dass die Daten im Notfall vollständig und innerhalb der geforderten Zeit wiederhergestellt werden können. Halten Sie fest, wer den Test ausführt, welche Schritte nötig sind und welche Ergebnisse als erfolgreich gelten.

Betriebsaufwand und Ausfallfolgen sauber zuordnen

Der Zeitaufwand lässt sich nicht durch einen allgemeinen Branchenwert ersetzen. Erfassen Sie die tatsächlichen Stunden Ihres Teams für Routinearbeiten und Vorfälle. Trennen Sie wiederkehrende Aufgaben von unregelmäßigen Ereignissen, damit eine einzelne intensive Wartungsphase nicht als typischer Monatsaufwand erscheint.

Zur Erfassung gehören mindestens:

• Updates, Sicherheitskorrekturen und Datenbankwartung;
• Kontrolle von Metriken, Speicherwachstum und Backupstatus;
• Planung und Durchführung von Wiederherstellungstests;
• Bereitschaft, Diagnose und Reaktion bei Störungen;
• Dokumentation, Zugriffsverwaltung und Übergaben im Team.

Wird bei einem kleinen Team die Ersparnis durch Betriebszeit aufgezehrt?
Das kann passieren, wenn wenige Personen alle Aufgaben neben ihrer übrigen Arbeit übernehmen oder wenn eine Störung nicht zuverlässig abgedeckt ist. Ersetzen Sie die Arbeitszeit nicht durch einen erfundenen Standard-Stundensatz. Erfassen Sie, wie viele Stunden das Team tatsächlich benötigt, und bewerten Sie diese mit dem internen Verrechnungssatz, den Ihr Unternehmen für Budgetentscheidungen verwendet.

Notieren Sie ebenso die möglichen Folgen einer Unterbrechung, ohne einen pauschalen Schadensbetrag anzusetzen. Entscheidend ist, welches Wiederherstellungsziel fachlich notwendig ist und wie lange die Anwendung ausfallen darf. Fragen Sie außerdem, welche Aufgaben der verwaltete Dienst übernimmt und welche weiterhin beim Team liegen. Die offizielle Beschreibung von Speicheroptionen für verwaltete Datenbanken ist ein Beispiel dafür, dass selbst die Speicherauswahl Teil der Architektur- und Kostenentscheidung ist; die konkrete Abrechnung und Funktion müssen Sie beim jeweils geprüften Angebot nachlesen.

Erst prüfen, dann mit tatsächlichen Kosten rechnen

Die folgende Checkliste ist das Entscheidungstor vor einer Migration. Wenn ein Punkt offen bleibt, sollte das Team die Annahme zunächst klären oder die verwaltete Lösung weiterführen. Eine Migration ist erst dann sinnvoll zu planen, wenn Ressourcenbedarf, Betriebszuständigkeit und Datenwiederherstellung zusammenpassen.

• [ ] Die Last ist über einen repräsentativen Zeitraum erfasst; Durchschnitt und Spitzen sind getrennt.
• [ ] Datenwachstum, Protokolle, Aufbewahrungsfristen und externe Backups sind in der Kapazitätsplanung enthalten.
• [ ] Das Team hat Verantwortliche für Updates, Monitoring, Sicherheitskorrekturen und Störungsreaktion benannt.
• [ ] Die Backupstrategie liegt außerhalb der Datenbankmaschine und die Wiederherstellung wurde praktisch getestet.
• [ ] Redundanz ist als konkrete Architektur geplant; zwei direkt angeschlossene Laufwerke werden nicht mit einem RAID-1 gleichgesetzt.
• [ ] Verfügbarkeits- und Wiederherstellungsziele sind für beide Betriebsmodelle vergleichbar dokumentiert.
• [ ] Preise stammen aus den aktuellen offiziellen Angebotsseiten beziehungsweise der aktuellen NodeKVM-Produktübersicht.
• [ ] Der Eigenbetrieb zeigt auch nach Backup, Redundanz und Teamaufwand einen nachvollziehbaren Vorteil.

Kostenvergleich verwaltete Datenbank oder Eigenbetrieb: Welche Werte gehören in die Kalkulation?
Erfassen Sie direkte Ausgaben, interne Arbeitszeit und Wiederherstellungsmaßnahmen getrennt. Erst danach bilden Sie Monats- und Jahressummen. Die folgenden Vorlagen vermeiden einen Scheingenauigkeitsvergleich: Tragen Sie nur Werte ein, die für Ihren Workload belegt sind.

Für die Jahresrechnung verwenden Sie dieselbe Systematik in beiden Spalten:

Jahreskosten = direkte Jahresausgaben + interne Betriebszeit + Backup- und Wiederherstellungsaufwand.

Die Arbeitszeit sollten Sie zusätzlich als Stunden ausweisen, statt sie in einer einzigen Summe zu verstecken. So kann das Team die Rechnung mit einem anderen internen Verrechnungssatz erneut prüfen, ohne die zugrunde liegenden Tätigkeiten neu schätzen zu müssen.

Nutzen Sie bei jeder aktualisierten Berechnung die Werte der jeweiligen offiziellen Angebotsseite. Ein auf einer Website angezeigter Kostenrechner ersetzt nicht die Dokumentation der Eingaben. Halten Sie Region, Ressourcen, Sicherungsoptionen und Abrechnungszeitraum im Kalkulationsblatt fest. Für die eigene Hardware gehören die aktuellen NodeKVM-Produktangaben und der tatsächlich ausgewählte Abrechnungszeitraum in dieselbe Vergleichsdatei.

Migration erst nach bestandener Kosten- und Betriebsprüfung

Beginnen Sie mit einem Kostenblatt für denselben Workload und denselben Wiederherstellungsanspruch. Ergänzen Sie danach Messwerte, Backupplan und tatsächlich erfasste Betriebsstunden. Wenn der Eigenbetrieb nur bei ausgelassenen Sicherungen, unberücksichtigter Redundanz oder unbezahlter Teamzeit günstiger erscheint, ist der Vergleich noch nicht entscheidungsreif.

Für die Migration sollte das Team anschließend einen Test außerhalb des produktiven Systems durchführen. Prüfen Sie dabei Datenübernahme, Konsistenz, Anwendungszugriff, Backup und Wiederherstellung. Dokumentieren Sie, wie die Rückkehr zur bisherigen Lösung erfolgen kann, bevor ein produktiver Wechsel terminiert wird. Geht ein Wiederherstellungstest fehl oder fehlt eine verantwortliche Person für Störungen, bleibt die verwaltete Datenbank zunächst die risikoärmere Wahl.

Wer nach diesem Vergleich eine dauerhaft stabile Last, ausreichende Betriebsressourcen und ein belastbares Backupkonzept nachweisen kann, sollte die Miete eines Datenbankservers mit unabhängiger Hardware und direktem NVMe-Speicher gegen das verwaltete Angebot rechnen. Das ist besonders relevant, wenn gemeinsam genutzte Ressourcen, variable Speicherabrechnung oder eingeschränkte Wahlmöglichkeiten beim Laufwerkslayout nicht zum eigenen Bedarf passen. Eine physische Maschine behebt jedoch weder fehlende Bereitschaft noch ungetestete Backups. Die passende Konfiguration und den aktuellen Preis sollte das Team anhand der tatsächlichen Messwerte auf der NodeKVM-Preisseite prüfen, bevor es die Migration freigibt.