Irgendwann findest du sie bei einer Inventur: eine MySQL-Instanz auf einem Server, der nie dafür vorgesehen war, gestartet unter einem Dienstkonto, das niemand mehr zuordnen kann, zuletzt aktualisiert an einem Datum, das im Änderungsprotokoll nicht auftaucht. Sie läuft. Sie läuft sogar seit Jahren, sauber und unauffällig.
Und sie liegt auf einem Windows-Server, der für etwas ganz anderes lizenziert wurde. Das ist kein Betriebsunfall, sondern das Ergebnis einer vernünftigen Entscheidung, die mit der Zeit teuer wird.
Ein Team, ein Betriebssystem, ein Patchday
Der Grund, warum Open-Source-Datenbanken auf Windows-Servern landen, hat selten etwas mit der Datenbank zu tun. MySQL bringt einen unterstützten Installer für Windows mit, PostgreSQL ebenfalls einen eigenen Windows-Build, und MariaDB verhält sich genauso. Technisch spricht nichts dagegen.
Meistens war es auch gar keine Architekturentscheidung. Die Datenbank landet dort meist durch:
- Ein Fachverfahren: Bringt seine eigene MySQL mit und richtet sie im Setup gleich ein.
- Einen Prototyp: Ein Entwickler braucht schnell eine Datenbank.
- Einen Dienstleister: Legt sie beim Rollout auf dem Server ab, der gerade freie Kapazität hatte.
Danach bleibt sie dort. Der Ausschlag kommt aus der Organisation: ein Team, ein Betriebssystem, ein Patchday, ein Monitoring, ein Backup-Job. Eine zusätzliche Instanz auf einem Blech, das du ohnehin betreust, kostet dich am Freitagnachmittag zehn Minuten. Eine Linux-VM daneben kostet dich eine zweite Werkzeugkette, eine zweite Härtungsrichtlinie und eine zweite Rufbereitschaft.
Die Engines, die deine Entwickler mitbringen, sind dabei überwiegend quelloffen. Laut der Stack Overflow Entwicklerumfrage 2024 haben diese Anteile der Befragten im vergangenen Jahr intensiv mit der jeweiligen Datenbank gearbeitet (Mehrfachnennungen möglich, die Summe liegt deshalb über 100 %):
- PostgreSQL: 48,7 %
- MySQL: 40,3 %
- Microsoft SQL Server: 25,3 %
Der Unterschied zu SQL Server liegt weniger in der Beliebtheit als im Betrieb. SQL Server bringt mit den Always-On-Verfügbarkeitsgruppen eine Hochverfügbarkeit mit, die auf dem Windows-Failovercluster aufsetzt und die dein Team schon kennt. Für MySQL und PostgreSQL fehlt dieses vertraute Werkzeug, Replikation und Failover baust du dort selbst auf.
Die Datenbank kommt also aus der einen Welt, die Plattform aus der anderen. Genau an dieser Naht entstehen die Kosten.
Die Lizenz zählt Kerne, nicht Datenbanken
Windows Server wird nach physischen Kernen lizenziert, und die Lizenzierungsrichtlinie von Microsoft nennt die Untergrenze klar: mindestens acht Kernlizenzen pro Prozessor und mindestens sechzehn Kernlizenzen pro Server.
Die Grenze trifft dich von unten, nicht von oben. Eine kleine Datenbankmaschine mit acht Kernen zahlt trotzdem sechzehn. Dazu kommt für jeden Benutzer oder jedes Gerät mit Zugriff eine CAL, und zwischen Standard und Datacenter liegt kein Leistungsunterschied, sondern ein Virtualisierungsrecht: zwei virtuelle Instanzen auf der einen Seite, unbegrenzt viele auf der anderen.
Die zweite Rechnung steht nicht auf der Lizenz. Der Patchday ist im Windows-Ökosystem ein Neustart-Termin, und ein Neustart ist für eine Datenbank etwas anderes als für einen Dateiserver: offene Transaktionen, ein kalter Buffer Pool, Anwendungen, die ihre Verbindungen erst nach dem Timeout neu aufbauen. Du planst also entweder ein Wartungsfenster für alles, was an dieser Datenbank hängt, oder du schiebst Patches auf, was ebenfalls eine Entscheidung ist.
Und die dritte Rechnung liegt im Backup. Die gewohnten Werkzeuge im Windows-Umfeld denken in Dateien. Eine Datenbank denkt in Transaktionen. Die Kopie eines laufenden Datenverzeichnisses ist kein konsistentes Backup, und eine Wiederherstellung auf einen bestimmten Zeitpunkt funktioniert nur, wenn das Binärlog mitgesichert und aufbewahrt wird. Wer das nicht ausdrücklich eingerichtet hat, besitzt Sicherungen, aber keine Wiederherstellungspunkte.
Gepatcht wird trotzdem, nur nicht mehr von dir
Der Reiz eines verwalteten Dienstes liegt für dich als Windows-Administrator nicht im Preis, sondern darin, dass du für diesen einen Baustein kein zweites Betriebssystem lernen musst. Engine-Patches, Backups, Wiederherstellung auf einen Zeitpunkt und die Verwaltung der Replikation übernimmt der Anbieter. Ein Linux-Prompt taucht dabei nicht auf.
Deine Anwendungen merken davon wenig. Ein Connection String verbindet die Anwendung mit der Datenbank, nicht den Server mit dem Arbeitsplatz, und genau deshalb bleibt er der einzige Berührungspunkt: Host, Port, Zertifikat werden getauscht, ODBC und ADO.NET bleiben, wie sie sind. Der Code, der diese Verbindung aufbaut, wird nicht angefasst.
Eines ändert sich trotzdem: Ein neuer Verbindungsaufbau zum Rechenzentrum dauert länger als zum Server im eigenen Netz. Deshalb lohnt ein Connection Pool, der offene Verbindungen wiederverwendet. Verwaltete Dienste bieten ihn oft selbst an, auf Anwendungsseite übernehmen das ProxySQL für MySQL oder PgBouncer für PostgreSQL.
Wer Cloud Datenbanken einkauft, kauft in Wirklichkeit drei Dinge ein: Knoten, Aufbewahrungsdauer und eine Zusage zur Verfügbarkeit.
| Stufe | Knoten | Backup-Aufbewahrung | SLA / Failover |
|---|---|---|---|
| Discovery | 1 | 48 Stunden | keines / kein Failover |
| Production | 2 | 14 Tage | 99,95 % / 1 Failover |
| Advanced | 3 | 30 Tage | 99,99 % / 2 Failover |
Production arbeitet mit zwei Knoten und automatischem Failover, Advanced mit drei Knoten, zwei Failovern und Lesereplikaten. Die Verteilung über drei Verfügbarkeitszonen und das SLA von 99,99 % gelten für Bereitstellungen in einer 3-AZ-Region. Das ist der Teil, den du auf einem einzelnen Windows-Server nicht nachbauen kannst, ohne eine zweite Maschine, eine zweite Lizenz und ein getestetes Failover-Verfahren dazuzukaufen.
Die unterste Stufe ist ausdrücklich für Prototypen und Tests gedacht: ein Knoten, zwei Tage Historie, keine zugesicherte Verfügbarkeit. Wer eine produktive Datenbank dorthin schiebt, hat den Windows-Server nicht abgelöst, sondern nur die Zuständigkeit dafür abgegeben. Die Stufe entscheidet, ob du etwas gewonnen hast, nicht der Umzug.
Erst der Restore, dann der Umzug
Eine Migration beginnt nicht mit dem Dump, sondern mit einem Test, der oft ausgelassen wird: Spiel eine vorhandene Sicherung einmal vollständig in eine leere Instanz ein und miss, wie lange das dauert. Wer diese Zahl nicht kennt, kennt seine tatsächliche Ausfallzeit nicht.
Die gemessene Dauer ist dein reales RTO (Recovery Time Objective). Dein RPO (Recovery Point Objective), also die Datenmenge, die du im Ernstfall verlierst, ergibt sich aus dem Backup-Intervall und der Aufbewahrung des Binärlogs.
Was eine zu optimistische Annahme kosten kann, zeigt das Uptime Institute: In seiner Annual Outage Analysis 2026 gaben 57 % der Befragten an, dass ihr letzter größerer Ausfall mehr als 100.000 US-Dollar gekostet hat. Jeder Fünfte meldete mehr als eine Million.
Danach werden drei Dinge abgeglichen, bevor Daten fließen:
- Engine und Version, denn ein Downgrade ist bei MySQL kein vorgesehener Weg zurück
- Zeichensatz und Kollation, weil Sortierung und Vergleich sonst stillschweigend andere Ergebnisse liefern
- SQL-Modus und Zeitzone, die beide Verhalten verändern, ohne Fehler zu werfen
Der eigentliche Umzug läuft über einen konsistenten Dump mit Binärlog-Position und anschließende Replikation. Diesen Dump erzeugt mysqldump –single-transaction –source-data: Die InnoDB-Tabellen bleiben während des Exports beschreibbar, nur zu Beginn greift kurz eine globale Lesesperre. Unter MySQL 8.x ist die GTID-basierte Replikation die Alternative zur Binärlog-Position.
Unter Windows PowerShell 5.1 schreibst du den Dump mit –result-file= statt mit einer Umleitung, weil diese dort standardmäßig UTF-16 erzeugt und die Datei so nicht mehr sauber einlesbar ist. Diese eine Option spart dir einen halben Vormittag.
Über die Leitung zu einem Anbieter repliziert wird asynchron, nicht synchron. Synchrone Replikation setzt Latenzen voraus, die du zwischen deinem Serverraum und einem Rechenzentrum nicht bekommst. Für die Umstellung heißt das: Schreibzugriffe kurz anhalten, den Rückstand auf null laufen lassen, Connection String tauschen.
Den Rückstand zeigt SHOW REPLICA STATUS im Feld Seconds_Behind_Source: Erst wenn dort 0 steht und keine Schreibzugriffe mehr ankommen, schaltest du um.
Was danach kommt, gehört auf eine Liste und nicht ins Gedächtnis: Dienst deaktivieren statt löschen, Port schließen, den alten Backup-Job abschalten, die freigewordenen Kernlizenzen dokumentieren und die Instanz aus dem Monitoring nehmen. Ein abgeschalteter Server, den niemand abgemeldet hat, taucht im nächsten Audit wieder auf.
Darf der Server bleiben?
Oft ja. Wenn die Datenbank ein internes Werkzeug mit zwei Gigabyte und zwölf Benutzern versorgt, der Windows-Server ohnehin läuft und die Lizenz längst bezahlt ist, dann ist die zusätzliche Instanz eine Randnotiz.
Verwaltete Dienste geben dir bewusst keine Administratorrechte auf dem darunterliegenden Betriebssystem. Was diese Rechte braucht, zieht nicht mit um, insbesondere wenn die Anwendung:
- Eng mit dem Active Directory verzahnt ist.
- Auf lokale Freigaben zugreift.
- Werkzeuge einsetzt, die direkten Dateisystemzugriff erwarten.
Der Umzug lohnt sich dort, wo Arbeitszeit, Wartungsfenster und fehlende Wiederherstellungspunkte die eigentlichen Posten sind. Die Frage lautet also nicht, ob Datenbanken auf Windows-Servern laufen dürfen, sondern welche davon groß genug geworden sind, dass ihr Betrieb den Patchday deines Teams mitbestimmt.
Zuständig bleibst du
Ein Anbieter wird Auftragsverarbeiter, du bleibst Verantwortlicher. Daran ändert kein Standort und kein Zertifikat etwas, und ein Dienstleister kann dich nicht datenschutzkonform machen.
Was er kann, steht im Auftragsverarbeitungsvertrag nach Art. 28 DSGVO. Dort müssen Gegenstand und Dauer der Verarbeitung stehen, Art und Zweck, die Art der personenbezogenen Daten und die Kategorien betroffener Personen. Die technischen und organisatorischen Maßnahmen verweisen auf Art. 32, und für Unterauftragsverarbeiter gelten Abs. 2 und 4: nicht ohne Genehmigung, und nur mit denselben Pflichten weitergereicht.
Praktisch heißt das zwei Fragen an den Anbieter. Erstens: in welcher Region wird die Instanz angelegt, denn diese Entscheidung fällt bei der Erstellung und lässt sich später nicht nebenbei ändern. Zweitens: wessen Recht kann Herausgabe verlangen. Diese Frage folgt der Konzernstruktur des Anbieters und nicht der Postleitzahl des Racks, und sie gehört in die Auswahl und nicht in die Nachbetrachtung.
Fazit
Nimm die Maschine, auf der deine Datenbank läuft, und zähle die verbauten Kerne. Stell die Zahl neben die sechzehn Kernlizenzen, die du mindestens bezahlst. Dann sieh dir die drei Stufen oben an und frag dich, welche davon du dir mit eigener Hardware, eigenen Backups und eigener Replikation tatsächlich gebaut hast.
Die meisten Antworten liegen zwischen der ersten und der zweiten Zeile. Genau deshalb wandern diese Datenbanken.
Neueste Kommentare