PostgreSQL oder MySQL: Datenmodell vor Benchmark

PostgreSQL passt besonders dann, wenn eine Anwendung variable JSON-Dokumente nach unterschiedlichen Schlüsseln und Werten durchsuchen muss. MySQL ist eine ebenso begründbare Wahl, wenn bekannte JSON-Pfade gezielt indexiert werden können und das Team InnoDB bereits sicher betreibt. Maßgeblich sind die tatsächlichen Abfragen, gleichzeitige Änderungen und der Betriebsaufwand.

Ein Benchmark beantwortet nur, wie die getesteten Versionen unter den gewählten Bedingungen bestimmte Operationen ausführen. Für ein Datenmodell kommt hinzu, welche Angaben gemeinsam gelesen werden, welche unabhängig voneinander geändert werden und wo Transaktionen aufeinander warten. Diese Eigenschaften lassen sich aus einer einzelnen Latenzzahl nicht ableiten.

Transaktionen: Welche Änderungen treffen dieselbe Zeile?

Bei PostgreSQL betrifft die Sperre nach einer Änderung im JSONB-Feld die gesamte Tabellenzeile.

Bei parallelen Schreibvorgängen zählt, wie die Anwendung fachliche Einheiten auf Tabellenzeilen verteilt. Die PostgreSQL-Dokumentation zur Mehrversionierung beschreibt konsistente Sichten für lesende Abfragen: Gewöhnliche Lese- und Schreibzugriffe blockieren sich dabei nicht gegenseitig. Für ausdrücklich gesteuerte Konflikte stehen außerdem Sperren auf Zeilenebene zur Verfügung.

Auch InnoDB arbeitet mit Versionen und Zeilensperren. Das InnoDB-Transaktionsmodell verbindet Mehrversionierung mit Zwei-Phasen-Sperren und verwendet standardmäßig konsistente Lesezugriffe ohne Sperre. Die bloße Feststellung, dass ein System Mehrversionierung nutzt, trennt die beiden Kandidaten deshalb kaum. Interessanter sind die verwendete Transaktionsisolation, die betroffenen Zeilen und die Dauer schreibender Transaktionen.

Ein ausdrücklich hypothetisches Beispiel: Werden zwei unabhängig änderbare Einstellungen in derselben Zeile gespeichert, können gleichzeitige Änderungen an dieser Zeile aufeinander warten. Liegen die Einstellungen aus fachlichen Gründen in getrennten Zeilen, verändert sich dieser Konflikt. Das Schema beeinflusst damit die Wartezeit unter Last; ein schneller isolierter Lesezugriff sagt über diesen Effekt wenig aus. Eine Aufteilung ist allerdings nur sinnvoll, wenn sie auch zu den Beziehungen und Zugriffen der Anwendung passt.

JSON: Indexierbare Abfragen und Grenzen des Dokuments

PostgreSQL und MySQL erschließen JSON-Werte über unterschiedliche dokumentierte Indexwege.

PostgreSQL speichert JSONB in einem zerlegten Binärformat und kann Suchzugriffe darauf indexieren. Die PostgreSQL-Dokumentation zu JSONB beschreibt GIN-Indizes für Schlüssel und Schlüssel-Wert-Paare sowie unterschiedliche Operator-Klassen mit verschiedenen unterstützten Suchoperationen. Ein Index auf dem gesamten Dokument passt daher nicht automatisch zu jedem Ausdruck: Für häufig abgefragte Teilbereiche kann ein Ausdrucksindex die passendere Form sein.

Die Flexibilität beim Lesen beseitigt keine Schreibkonflikte. Wird ein JSON-Dokument in PostgreSQL aktualisiert, betrifft die Zeilensperre die gesamte Tabellenzeile. Wenn mehrere Vorgänge häufig verschiedene Teile desselben großen Dokuments ändern, liegt der mögliche Engpass folglich im Zuschnitt der gespeicherten Einheit. Für Inhalte, die nach den Geschäftsregeln unabhängig geändert werden, können getrennte Zeilen oder reguläre Spalten sinnvoller sein als ein gemeinsames JSON-Feld.

MySQL bietet einen nativen JSON-Typ und andere Wege zur Indexierung. Die MySQL-Dokumentation zum JSON-Typ beschreibt Indizes auf erzeugten Spalten, die skalare Werte aus einem JSON-Dokument extrahieren; InnoDB unterstützt zudem mehrwertige Indizes für JSON-Arrays. Unter bestimmten Bedingungen kann MySQL einen JSON-Wert teilweise aktualisieren, statt das gesamte Dokument neu zu schreiben. Diese Speicheroptimierung ersetzt keine Prüfung, ob die benötigten Suchausdrücke und gleichzeitigen Änderungen zum gewählten Schema passen.

Für die Auswahl ist deshalb die Form der Abfrage präziser als das Etikett „JSON-Unterstützung“: Werden wechselnde Schlüssel und enthaltene Werte gesucht, oder wiederholen sich wenige bekannte Pfade? Müssen häufig gefilterte Geschäftsmerkmale als reguläre Spalten zugänglich sein? Beide Systeme können JSON speichern, doch Index und Datenmodell müssen zu den konkreten Prädikaten und Änderungsmustern passen.

Benchmark: Die Rangfolge hängt vom Abfragetyp ab

Der Sysbench-Test misst einfache Einzelabfragen, während parallele Transaktionen und mehrere Tabellen außerhalb seines Testaufbaus liegen.

Der Sysbench-Vergleich von DoltHub mit PostgreSQL 15.5 und MySQL 8.0.35 meldet für „groupby_scan“ eine mediane Latenz von 5,28 gegenüber 14,46 Millisekunden; bei „index_join“ liegt MySQL mit 1,37 gegenüber 1,96 Millisekunden vorn. Selbst innerhalb dieser Messreihe wechselt die Führung also mit der Operation. Eine Anwendung, deren Antwortzeit von Joins geprägt ist, gewichtet die Ergebnisse anders als eine Anwendung mit vielen Gruppierungen.

Die Messung lief ohne besondere Datenbankkonfiguration auf einer EC2-Instanz mit angebundenem EBS-Speicher. Die getesteten Tabellen passten in den Arbeitsspeicher; die Suite wiederholte überwiegend einfache Einzelabfragen und enthielt zusätzlich eigens aufgenommene Join-Tests. Parallele Transaktionen gehörten nicht zum Testaufbau. Die Werte beschreiben damit diese Versionen, Hardware und Abfragen, aber keine allgemeine Geschwindigkeit eines später anders konfigurierten Systems.

Auch die Messgröße hat Folgen für die Interpretation. Eine Medianlatenz zeigt die Mitte der gemessenen Antwortzeiten für einen Test; sie beschreibt weder Wartezeiten durch konkurrierende Updates noch seltene besonders langsame Anfragen einer Anwendung. Für einen Vergleich des eigenen Workloads sind daher Datenverteilung, Indizes, Abfrageplan und gleichzeitige Last ebenso wichtig wie die gemessene Zeit. Ein einzelner Gesamtsieger würde diese Unterschiede verdecken.

Betrieb und Workload zusammen bewerten

Die technische Wahl wirkt über die Abfrage hinaus. Sicherungen müssen wiederherstellbar sein, Aktualisierungen geplant werden und Störungen im laufenden Betrieb beherrschbar bleiben. Ein Team mit erprobten InnoDB-Verfahren trägt bei MySQL andere Umstellungsrisiken als ein Team, dessen Anwendungscode, SQL-Ausdrücke und Betriebswerkzeuge bereits auf PostgreSQL ausgerichtet sind. Teamkompetenz ist damit ein konkreter Teil der Entscheidung, keine Eigenschaft, die sich aus einem Benchmark ablesen lässt.

Für die fachliche Auswahl lassen sich die offenen Fragen knapp ordnen:

Transaktionen: Welche Vorgänge ändern dieselben Zeilen, und wie lange bleiben ihre Transaktionen offen?
JSON: Werden variable Inhalte nach vielen Schlüsseln durchsucht, oder reichen Indizes für bekannte Pfade und Werte?
Abfragen: Bestimmen Joins, Gruppierungen, JSON-Suchen oder Schreibvorgänge die Antwortzeit unter realer Last?
Betrieb: Für welches System sind Sicherung, Wiederherstellung, Überwachung und Aktualisierung bereits verlässlich organisiert?

Überwiegen variable JSONB-Suchen und passt die Zeilenstruktur zu den Änderungen, verdient PostgreSQL eine nähere Prüfung. Decken gezielt indexierte JSON-Pfade, InnoDB-Transaktionen und vorhandene Betriebsverfahren den Bedarf gut ab, kann MySQL die passendere Entscheidung sein. Erst die danach verbleibenden Leistungsfragen sollten mit repräsentativen Abfragen und gleichzeitiger Last gemessen werden.

Lesen Sie auch: