PostgreSQL oder MySQL: die Stellen, an denen es kippt
Beide Systeme sind ausgereift und schnell genug. Die Entscheidung fällt an den Rändern: bei komplexen Auswertungen, bei Erweiterungen, beim Failover und beim Versionswechsel.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Die Wahl fällt oft aus Gewohnheit und rächt sich später
In den meisten Projekten wird die Datenbank nicht ausgewählt, sondern übernommen: Es gab schon eine, das Framework hatte eine Voreinstellung, oder jemand hatte mit dem einen System schon einmal zu tun. Das ist kein schlechtes Vorgehen, denn vorhandenes Wissen ist ein echtes Argument. Es wird erst dann teuer, wenn die Anwendung in einen Bereich hineinwächst, in dem sich die Systeme tatsächlich unterscheiden.
Die Rechnung kommt meist an zwei Stellen. Die erste ist die Auswertung: Sobald Berichte über mehrere Tabellen mit Fensterfunktionen, rekursiven Abfragen und großen Gruppierungen entstehen, wird der Unterschied zwischen den Optimierern sichtbar, und zwar in Sekunden. Die zweite ist der Betrieb: Wenn zum ersten Mal ein automatischer Wechsel auf einen zweiten Knoten gebraucht wird oder ein Sprung auf die nächste Hauptversion ansteht, unterscheiden sich Aufwand und Ausfallzeit deutlich.
Was in dieser Entscheidung kaum eine Rolle spielt, ist die reine Geschwindigkeit einfacher Zugriffe. Beide Systeme liefern einen Datensatz über den Primärschlüssel in einer Zeit, die in keinem Projekt den Ausschlag gibt. Wer die Wahl an Vergleichszahlen aus dem Netz festmacht, misst meist die Konfiguration und nicht das System.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Die Gegenüberstellung entlang der Kriterien, die im Projekt zählen
Beide Systeme sind quelloffen, ausgereift und für die allermeisten Anwendungen schnell genug. Die folgenden sieben Fragen sind die, bei denen sich die Antworten tatsächlich unterscheiden.
PostgreSQL
objektrelational, stark erweiterbar, mit ausgeprägtem Optimizer und transaktionalen Schemaänderungen
MySQL
verbreitet im Web-Umfeld, mit InnoDB als Standardspeicher und einem mitgelieferten Weg zu Hochverfügbarkeit
| Entscheidungsfrage | PostgreSQL | MySQL |
|---|---|---|
| Wie gut kommt das System mit komplexen Auswertungen zurecht? | Stärke Fensterfunktionen, rekursive Abfragen, LATERAL, FULL OUTER JOIN und materialisierte Sichten sind vorhanden, und einzelne Abfragen laufen auf mehreren Prozessorkernen parallel. | Kommt darauf an Fensterfunktionen und rekursive Abfragen gibt es seit Version 8.0, Hash Joins seit 8.0.18. Es fehlen weiterhin FULL OUTER JOIN und materialisierte Sichten, und eine einzelne Abfrage nutzt nur einen Kern. |
| Was passiert, wenn Teile der Daten als JSON ankommen? | Stärke Der Typ jsonb speichert zerlegt und lässt sich mit GIN-Indizes über beliebige Schlüssel durchsuchen, dazu kommt die Abfragesprache jsonpath. Auch Teilbereiche eines Dokuments lassen sich gezielt indizieren. | Stärke Der JSON-Typ speichert ebenfalls in einer zerlegten Form, indiziert wird über generierte Spalten oder Funktionsindizes, für Werte in Feldern gibt es mehrwertige Indizes. Das deckt die üblichen Fälle ab, verlangt aber mehr Vorarbeit je Zugriffspfad. |
| Wie weit lässt sich das System um Funktionen erweitern, die es ab Werk nicht hat? | Stärke Erweiterungen werden mit CREATE EXTENSION eingebunden und bringen eigene Typen, Funktionen und Indexarten mit, von Geodaten über Zeitreihen bis zur Ähnlichkeitssuche über Vektoren. Alles bleibt in derselben Datenbank und derselben Transaktion. | Schwäche Erweiterbar ist vor allem die Speicher-Ebene über Engines und Plugins. Für Aufgaben wie Vektorsuche oder Zeitreihen steht kein vergleichbares Ökosystem bereit, sie landen in einem zweiten System neben der Datenbank. |
| Wie viel Eigenbau steckt in einem automatischen Failover? | Kommt darauf an Physische und logische Replikation sind eingebaut und zuverlässig, den Wechsel auf den zweiten Knoten übernimmt aber keine mitgelieferte Komponente. Dafür braucht es zusätzliche Software wie Patroni, repmgr oder pg_auto_failover samt eigenem Betriebswissen. | Stärke Group Replication, der Router und die Shell ergeben zusammen einen abgestimmten Weg zum automatischen Wechsel, und die Anwendung verbindet sich gegen den Router statt gegen einen festen Knoten. |
| Was kostet der Sprung auf die nächste Hauptversion? | Kommt darauf an Das Format auf der Platte ändert sich mit jeder Hauptversion, deshalb ist pg_upgrade nötig, im schnellen Modus mit harten Verweisen statt Kopien. Für sehr kurze Ausfallzeiten führt der Weg über logische Replikation auf eine zweite Instanz. | Stärke Der Wechsel erfolgt an Ort und Stelle: neue Programmversion starten, das Datenverzeichnis wird beim Start übernommen. Das ist deutlich weniger Vorbereitung, verlangt aber ebenso einen geprüften Rückweg über eine Sicherung. |
| Wie sicher laufen Schemaänderungen im Auslieferungspaket? | Stärke Schemaänderungen laufen in Transaktionen. Mehrere Änderungen lassen sich gemeinsam bestätigen oder gemeinsam zurücknehmen, ein abgebrochenes Auslieferungspaket hinterlässt keinen halben Stand. | Kommt darauf an Jede Schemaänderung bestätigt die laufende Transaktion sofort und ist damit endgültig. Seit 8.0 ist eine einzelne Änderung wenigstens absturzsicher, ein Zurücknehmen mehrerer Schritte als Einheit gibt es aber nicht. |
Wie gut kommt das System mit komplexen Auswertungen zurecht?
Fensterfunktionen, rekursive Abfragen, LATERAL, FULL OUTER JOIN und materialisierte Sichten sind vorhanden, und einzelne Abfragen laufen auf mehreren Prozessorkernen parallel.
Fensterfunktionen und rekursive Abfragen gibt es seit Version 8.0, Hash Joins seit 8.0.18. Es fehlen weiterhin FULL OUTER JOIN und materialisierte Sichten, und eine einzelne Abfrage nutzt nur einen Kern.
Was passiert, wenn Teile der Daten als JSON ankommen?
Der Typ jsonb speichert zerlegt und lässt sich mit GIN-Indizes über beliebige Schlüssel durchsuchen, dazu kommt die Abfragesprache jsonpath. Auch Teilbereiche eines Dokuments lassen sich gezielt indizieren.
Der JSON-Typ speichert ebenfalls in einer zerlegten Form, indiziert wird über generierte Spalten oder Funktionsindizes, für Werte in Feldern gibt es mehrwertige Indizes. Das deckt die üblichen Fälle ab, verlangt aber mehr Vorarbeit je Zugriffspfad.
Wie weit lässt sich das System um Funktionen erweitern, die es ab Werk nicht hat?
Erweiterungen werden mit CREATE EXTENSION eingebunden und bringen eigene Typen, Funktionen und Indexarten mit, von Geodaten über Zeitreihen bis zur Ähnlichkeitssuche über Vektoren. Alles bleibt in derselben Datenbank und derselben Transaktion.
Erweiterbar ist vor allem die Speicher-Ebene über Engines und Plugins. Für Aufgaben wie Vektorsuche oder Zeitreihen steht kein vergleichbares Ökosystem bereit, sie landen in einem zweiten System neben der Datenbank.
Wie viel Eigenbau steckt in einem automatischen Failover?
Physische und logische Replikation sind eingebaut und zuverlässig, den Wechsel auf den zweiten Knoten übernimmt aber keine mitgelieferte Komponente. Dafür braucht es zusätzliche Software wie Patroni, repmgr oder pg_auto_failover samt eigenem Betriebswissen.
Group Replication, der Router und die Shell ergeben zusammen einen abgestimmten Weg zum automatischen Wechsel, und die Anwendung verbindet sich gegen den Router statt gegen einen festen Knoten.
Was kostet der Sprung auf die nächste Hauptversion?
Das Format auf der Platte ändert sich mit jeder Hauptversion, deshalb ist pg_upgrade nötig, im schnellen Modus mit harten Verweisen statt Kopien. Für sehr kurze Ausfallzeiten führt der Weg über logische Replikation auf eine zweite Instanz.
Der Wechsel erfolgt an Ort und Stelle: neue Programmversion starten, das Datenverzeichnis wird beim Start übernommen. Das ist deutlich weniger Vorbereitung, verlangt aber ebenso einen geprüften Rückweg über eine Sicherung.
Wie sicher laufen Schemaänderungen im Auslieferungspaket?
Schemaänderungen laufen in Transaktionen. Mehrere Änderungen lassen sich gemeinsam bestätigen oder gemeinsam zurücknehmen, ein abgebrochenes Auslieferungspaket hinterlässt keinen halben Stand.
Jede Schemaänderung bestätigt die laufende Transaktion sofort und ist damit endgültig. Seit 8.0 ist eine einzelne Änderung wenigstens absturzsicher, ein Zurücknehmen mehrerer Schritte als Einheit gibt es aber nicht.
Was passt wann
- Wenn die Anwendung viele einfache Zugriffe nach Schlüssel macht und ein automatischer Knotenwechsel ohne Zusatzsoftware gewünscht ist
- nimm MySQL und richte von Anfang an einen InnoDB-Cluster mit Router ein.
- Wenn Berichte über viele Tabellen laufen, mit Fensterfunktionen und rekursiven Abfragen, oder wenn du Geodaten, Zeitreihen oder Vektorsuche brauchst
- nimm PostgreSQL und plan die Erweiterungen gleich mit ein.
- Wenn dein Team eines der beiden Systeme seit Jahren betreibt und der Anwendungsfall in keinem der Kriterien deutlich ausschlägt
- bleib beim vertrauten System, denn das Betriebswissen ist an dieser Stelle mehr wert als jede Funktionsliste.
Sechs Fragen, die die Wahl entscheiden
- 01 Wie komplex werden die Auswertungen über mehrere Tabellen hinweg?
- 02 Brauchst du Funktionen, die keines der Systeme ab Werk mitbringt?
- 03 Muss ein Knotenausfall automatisch aufgefangen werden?
- 04 Wie viel Ausfallzeit darf ein Hauptversionswechsel kosten?
- 05 Wie oft laufen Schemaänderungen, und was passiert bei einem Abbruch?
- 06 Welches System kann dein Team im Störungsfall tatsächlich bedienen?
Was du nach dieser Seite entscheiden kannst
Die Frage lautet nicht, welches System besser ist, sondern welche dieser Unterscheidungen für dein Vorhaben zutrifft. Meistens sind es ein oder zwei, und die geben dann den Ausschlag, während der Rest austauschbar bleibt.
Den Anspruch der Auswertungen einschätzen
Fensterfunktionen, rekursive Abfragen und materialisierte Sichten sind der Bereich, in dem PostgreSQL deutlich vorne liegt. Bei überwiegend einfachen Zugriffen nach Schlüssel spielt der Unterschied keine Rolle.
Den Bedarf an Erweiterungen prüfen
Geodaten, Zeitreihen oder Ähnlichkeitssuche über Vektoren löst PostgreSQL über Erweiterungen im selben System. In MySQL landet so etwas in einer zweiten Datenbank daneben.
Das Failover mitplanen
MySQL bringt mit Group Replication, Router und Shell einen zusammenhängenden Weg zum automatischen Wechsel mit. PostgreSQL braucht dafür zusätzliche Software wie Patroni oder repmgr.
Den Versionswechsel einrechnen
MySQL aktualisiert das Datenverzeichnis beim Start der neuen Version an Ort und Stelle. PostgreSQL verlangt pg_upgrade oder logische Replikation, weil sich das Dateiformat je Hauptversion ändert.
Migrationen sicher machen
PostgreSQL führt Schemaänderungen in Transaktionen aus, ein fehlgeschlagenes Auslieferungspaket hinterlässt keinen halben Zustand. MySQL bestätigt jede Schemaänderung sofort und endgültig.
Das vorhandene Wissen ehrlich bewerten
Wer nachts um drei die Wiederherstellung bedienen muss, entscheidet mehr über die Verfügbarkeit als jede Funktionsliste. Ein vertrautes System schlägt ein theoretisch besseres.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Wo die beiden herkommen und was davon geblieben ist
MySQL kommt aus dem Web-Umfeld und war lange auf schnelles Lesen ausgelegt, notfalls auf Kosten der Strenge. Vieles davon ist inzwischen korrigiert: InnoDB ist der Standardspeicher mit Transaktionen und Fremdschlüsseln, der strenge Modus verhindert das stillschweigende Abschneiden von Werten, und das Datenwörterbuch ist seit Version 8.0 selbst transaktional. Geblieben ist die Architektur mit austauschbaren Speicher-Engines und ein Ökosystem, in dem jede Hosting-Umgebung MySQL anbietet.
PostgreSQL kommt aus der akademischen Ecke und war von Anfang an darauf ausgelegt, erweiterbar zu sein. Eigene Datentypen, eigene Operatoren, eigene Indexarten und eigene Prozedursprachen sind Teil der Bauweise, nicht ein nachträglicher Aufsatz. Daraus ist das entstanden, was heute den größten Unterschied ausmacht: ein Vorrat an Erweiterungen, mit denen sich Aufgaben in derselben Datenbank lösen lassen, für die sonst ein zweites System nötig wäre.
Bei den Lizenzen unterscheiden sie sich ebenfalls. PostgreSQL steht unter einer freizügigen Lizenz nach dem Vorbild der BSD-Lizenzen, MySQL wird von Oracle unter der GPL und zusätzlich unter kommerziellen Bedingungen angeboten, wobei einige Funktionen wie die Maskierungsfunktionen der Enterprise-Ausgabe vorbehalten sind. Für den Betrieb im eigenen Haus spielt das selten eine Rolle. Sobald die Datenbank als Teil eines eigenen Produkts weitergegeben wird, gehört der Lizenztext auf den Tisch und die Bewertung zu denen, die im Haus für Verträge zuständig sind.
Der Unterschied, der sich bei Auswertungen zuerst zeigt
Solange Abfragen einzelne Datensätze über den Primärschlüssel holen, ist zwischen beiden kaum ein Unterschied messbar. Er entsteht, sobald mehrere große Tabellen verknüpft, gruppiert und sortiert werden. PostgreSQL kann eine einzelne Abfrage auf mehrere Prozessorkerne verteilen, für den Tabellenzugriff ebenso wie für Verknüpfungen und Gruppierungen. MySQL arbeitet eine Abfrage in einem Ausführungsstrang ab, was bei einem Bericht über Millionen Zeilen den Unterschied zwischen Sekunden und Minuten ausmacht.
Dazu kommen einzelne fehlende Bauteile. FULL OUTER JOIN gibt es in MySQL nicht, es wird über eine Vereinigung zweier äußerer Verknüpfungen nachgebaut. Materialisierte Sichten fehlen ebenfalls, an ihre Stelle treten selbst gepflegte Zusammenfassungstabellen mit einem Job. Hash Joins hat MySQL erst mit 8.0.18 bekommen, davor blieb bei großen Verknüpfungen ohne passenden Index nur die verschachtelte Schleife.
Für die Praxis heißt das nicht, dass Auswertungen mit MySQL unmöglich wären. Es heißt, dass mehr Arbeit in die Vorbereitung wandert: passende Indizes, vorberechnete Tabellen, aufgeteilte Abfragen. Wenn die Anwendung ihre Berichte ohnehin in ein eigenes Auswertungssystem auslagert, verliert dieser Punkt an Gewicht.
Betrieb: Speicherverwaltung und der Sprung auf die nächste Hauptversion
Beide arbeiten mit Zeilenversionen, damit Lesevorgänge nicht blockieren, legen die alten Versionen aber unterschiedlich ab. InnoDB schreibt sie in eigene Bereiche und räumt sie mit einem Hintergrundprozess wieder ab. PostgreSQL lässt die alten Versionen in der Tabelle selbst stehen, weshalb es Vacuum braucht: Autovacuum räumt laufend auf, und wenn er nicht hinterherkommt, wachsen Tabellen und Indizes auf ein Vielfaches ihrer Nutzgröße. Lange offene Transaktionen sind dabei der häufigste Auslöser, weil sie das Aufräumen blockieren.
Beim Hauptversionswechsel dreht sich das Bild. MySQL übernimmt das Datenverzeichnis beim Start der neuen Version an Ort und Stelle, für die meisten Installationen ist das eine überschaubare Wartungsphase. PostgreSQL ändert das Format auf der Platte mit jeder Hauptversion, deshalb ist pg_upgrade nötig. Im schnellen Modus arbeitet es mit harten Verweisen statt mit Kopien, was die Dauer stark verkürzt, aber einen sauberen Rückweg über die Sicherung voraussetzt, weil die alte Instanz danach nicht mehr benutzbar ist. Wer nur Minuten Ausfallzeit hat, geht den Weg über logische Replikation auf eine zweite Instanz mit der neuen Version.
Ein Punkt, der in beiden Lagern unterschätzt wird, betrifft Sortierregeln. Ändert sich beim Wechsel des Betriebssystems die Sortierreihenfolge der zugrunde liegenden Systembibliothek, stimmen Textindizes in PostgreSQL nicht mehr mit den Daten überein und müssen neu aufgebaut werden. In MySQL ist die entsprechende Falle die Sortierregel selbst: Der Standard vergleicht Text ohne Rücksicht auf Groß- und Kleinschreibung, was viele Anwendungen stillschweigend voraussetzen und beim Umstieg auf PostgreSQL plötzlich anders vorfinden.
Hochverfügbarkeit: mitgeliefert oder zusammengebaut
MySQL liefert für den automatischen Wechsel ein aufeinander abgestimmtes Paket: Group Replication sorgt für die Abstimmung zwischen den Knoten, der Router leitet Verbindungen auf den jeweils schreibenden Knoten, und die Shell richtet den Verbund ein und überwacht ihn. Die Anwendung verbindet sich gegen den Router und muss von einem Wechsel nichts wissen. Das ist ein echter Vorteil für Teams, die keine eigene Betriebsmannschaft für die Datenbank haben.
PostgreSQL bringt die Replikation mit, den Wechsel aber nicht. Physische Replikation überträgt die Schreibprotokolle auf einen zweiten Knoten, logische Replikation überträgt einzelne Tabellen und funktioniert auch zwischen verschiedenen Hauptversionen. Wer daraus ein automatisches Failover machen will, ergänzt Patroni, repmgr oder pg_auto_failover und braucht dazu eine Instanz für die Abstimmung sowie einen Verbindungsverteiler davor. Das läuft stabil, ist aber ein eigenes Bauwerk mit eigenen Ausfallmöglichkeiten.
Wenn die Datenbank ohnehin als betreuter Dienst bei einem Anbieter läuft, verliert dieser Unterschied stark an Bedeutung, denn dort ist das Failover Teil des Dienstes. Dann verschiebt sich die Frage darauf, welche Erweiterungen der Anbieter zulässt und wie schnell er neue Hauptversionen nachzieht.
Die Fallen im ersten Projekt, und warum das Team am Ende entscheidet
Bei MySQL sind es meist drei. Erstens der Zeichensatz: Der Name utf8 stand historisch für eine Variante mit höchstens drei Byte je Zeichen, die keine Emojis abbilden kann, richtig ist utf8mb4. Zweitens die Groß- und Kleinschreibung bei Tabellennamen, die davon abhängt, wie der Server eingestellt ist und wie das Dateisystem arbeitet, weshalb ein Wechsel von Windows nach Linux Anwendungen zerlegt. Drittens die sofortige Bestätigung bei Schemaänderungen, die Auslieferungspakete mit mehreren Schritten unsicher macht.
Bei PostgreSQL sind es ebenfalls drei. Jede Verbindung ist ein eigener Prozess, weshalb Anwendungen mit vielen kurzlebigen Verbindungen einen Verbindungsverteiler wie PgBouncer davorstellen sollten. Lange offene Transaktionen blockieren das Aufräumen und lassen Tabellen wachsen, auch wenn nichts geschrieben wird. Und der Suchpfad mit dem Schema public überrascht regelmäßig alle, die aus einer Welt kommen, in der Datenbank und Schema dasselbe sind, denn in PostgreSQL sind es zwei Ebenen.
Bleibt der Punkt, der in keiner Merkmalsliste steht. Die Verfügbarkeit einer Datenbank hängt weniger von ihren Funktionen ab als davon, ob jemand im Störungsfall weiß, was zu tun ist: wo die Protokolle liegen, wie eine Wiederherstellung abläuft, was die üblichen Warnzeichen sind. Ein System, das im Haus seit Jahren betrieben wird, ist an dieser Stelle einem theoretisch besseren überlegen, und diese Überlegung sollte in der Entscheidung genauso viel Gewicht bekommen wie die Funktionstabelle.
Dazu passende Kurse
Die Unterschiede werden greifbar, sobald dieselbe Aufgabe zweimal gelöst wird, und dafür gibt es bei cmt Kurse zu beiden Systemen im direkten Vergleich .
Wenn die Entscheidung auf PostgreSQL gefallen ist, führt der Weg über die PostgreSQL-Reihe vom SQL-Einstieg bis zum Tuning .
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Super Schulung, in der der Trainer auch auf eigene Fragestellungen eingegangen ist.
Super Grundlagenschulung mit allen wichtigen Punkten und hilfreichen Tipps!
Schön, sich 5 Tage ungestört mit Postgres beschäftigen zu können.
Häufige Fragen
Ist der Wechsel von MySQL zu PostgreSQL aufwendig?
Und wo steht MariaDB in dieser Frage?
Welches System ist schneller?
Spielt die Wahl noch eine Rolle, wenn wir einen betreuten Dienst nutzen?
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Datenbanken-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Zwei Systeme nebeneinander verstehen statt eines auswendig lernen
Wer beide Systeme einmal an denselben Aufgaben gesehen hat, entscheidet im nächsten Projekt in einer Stunde, und bei cmt lassen sich beide Wege nacheinander gehen.