PostgreSQL oder MySQL für langlebige Systeme

Kaum eine technische Wahl wird so oft zum Lagerkampf wie die zwischen diesen beiden Datenbanken — und kaum eine ist für die meisten Systeme so wenig entscheidend, wie der Streit vermuten lässt. Beide sind seit Langem reif, beide sind relationale Datenbanken mit stabilen Grundlagen, beide werden in zehn Jahren noch gepflegt und besetzbar sein. Wer eine von beiden wählt, wählt fast nie falsch — der Fehler liegt woanders, in der Art, wie man die Daten modelliert und die Datenbank betreibt.

Dieses Dokument behandelt die Wahl deshalb nüchtern: Es benennt, was die beiden teilen, wo sie sich wirklich unterscheiden, und an welchen wenigen Merkmalen die Entscheidung sinnvoll hängt. Es kürt keinen Sieger, weil es keinen gibt — es beschreibt, wofür jede die passendere ist. Die Prinzipien gelten unabhängig von der Version; genannt werden keine Zahlen und keine Vergleichsmessungen.

1. Die falsche Frage

„Welche ist besser?" ist die falsche Frage, weil sie eine allgemeine Antwort erwartet, wo es nur situationsabhängige gibt. Beide Datenbanken sind für den weit überwiegenden Teil betrieblicher Systeme mehr als ausreichend; ihre Unterschiede werden erst an den Rändern spürbar, in besonderen Anforderungen an Datentypen, Nebenläufigkeit oder Betrieb. Für das mittlere System — Tabellen, Beziehungen, Transaktionen, überschaubare Last — liefern beide dasselbe: Verlässlichkeit über Jahre.

Der Streit hält sich auch deshalb, weil Werkzeugwahl leicht zur Identität wird — man verteidigt, was man kennt, als wäre es ein Teil seiner selbst. Das ist menschlich, aber es ist kein Argument. Eine nüchterne Entscheidung trennt die Vorliebe von der Passung und fragt nicht, womit man sich wohler fühlt, sondern was das System braucht.

Die bessere Frage lautet: Welche passt zu der Form meiner Daten und zu dem Team, das sie betreiben wird? Diese Frage hat eine Antwort, und sie ist nützlich. Wer stattdessen ein Ranking sucht, führt einen Streit, dessen Ausgang für sein System kaum Folgen hat — und übersieht darüber die Entscheidungen, die wirklich zählen: das Datenmodell, die Indizierung, die Disziplin der Migrationen.

Trade-off. Die Frage nüchtern zu stellen bedeutet, auf die Bequemlichkeit einer allgemeinen Empfehlung zu verzichten und für das eigene System zu urteilen.

Kosten. Das Urteil verlangt, die eigene Datenform und die Stärken des eigenen Teams ehrlich einzuschätzen — mehr Arbeit als ein Blick auf ein Ranking.

Wann wir anders entscheiden. Wo ein Team eine der beiden längst tief beherrscht und betreibt, ist die Frage oft schon entschieden: Die vertraute, gut betriebene Datenbank schlägt die theoretisch etwas passendere, die niemand sicher bedient.

2. Was beide gemeinsam haben

Der größte Teil der Wahrheit über diese beiden Datenbanken ist, was sie teilen. Beide sind relationale Datenbanken mit Tabellen, Beziehungen und der Abfragesprache SQL. Beide bieten Transaktionen mit den Garantien, auf die man sich bei Geld und Zustand verlassen muss. Beide sind über viele Jahre gereift, tragen große Systeme, haben tiefe Dokumentation, einen großen Kreis von Kennern und eine gesicherte Zukunft. Beide wird man in zehn Jahren noch pflegen und besetzen können.

Aus dieser Gemeinsamkeit folgt die entlastende Einsicht: Für die meisten Systeme ist die Wahl reversibel genug und die Fähigkeit ähnlich genug, dass man sich nicht verrennen kann. Wer bei einer von beiden bleibt und sauber modelliert, baut auf solidem Grund — unabhängig davon, welche es geworden ist. Die Reife beider ist der eigentliche Gewinn; sie ist der Grund, warum die Wahl seltener kritisch ist, als es scheint.

Es lohnt, dieses gemeinsame Fundament zu würdigen, weil es der weitaus größte Teil dessen ist, was ein System von seiner Datenbank braucht. Daten sicher speichern und wiederfinden; Beziehungen abbilden; in Transaktionen ändern, ohne halbe Zustände zu hinterlassen; unter Last verlässlich antworten; über Jahre gepflegt und verstanden werden. All das leisten beide, und all das ist der Kern. Die Unterschiede, um die gestritten wird, betreffen den schmalen Rand darüber hinaus. Ein Team, das das Fundament sauber nutzt, hat mit jeder der beiden ein gutes System; ein Team, das es schlecht nutzt, rettet auch die theoretisch überlegene Datenbank nicht.

Trade-off. Die Gemeinsamkeit anzuerkennen bedeutet, die Wahl weniger dramatisch zu nehmen, als der Markt sie inszeniert — das nimmt ihr die falsche Wucht.

Kosten. Wer die Ähnlichkeit unterschätzt, verschwendet Energie an eine Entscheidung, die wenig bewegt, statt an das Datenmodell, das viel bewegt.

Wann wir anders entscheiden. Nur wo eine besondere Anforderung genau an einem der Unterschiede hängt (siehe nächste Kapitel), wird die Gemeinsamkeit zweitrangig und der Unterschied entscheidend.

3. Wo sie sich wirklich unterscheiden

Die Unterschiede sind real, aber sie liegen an den Rändern, nicht im Kern. Grob gesagt neigt die eine — PostgreSQL — zu Reichtum und Strenge: mehr Datentypen, mehr Erweiterbarkeit, eine ausgeprägte Sorgfalt bei Korrektheit und komplexen Abfragen. Die andere — MySQL — neigt zu Einfachheit und Verbreitung: geradliniger im Betrieb für den Standardfall, extrem weit verbreitet, mit einem großen Fundus an Erfahrung für gängige Muster. Das sind Neigungen, keine Grenzen; vieles, was die eine kann, kann die andere auch, nur mit anderem Aufwand.

Ein greifbares Beispiel, ohne Partei zu ergreifen: der Umgang mit halbstrukturierten Daten und mit ungültigen Eingaben. Wo ein System viele Daten trägt, die sich nicht sauber in Spalten fügen, spielt die reichere Neigung ihre Ausdruckskraft aus; wo eine Datenbank streng jede unerlaubte Eingabe zurückweist, statt sie stillschweigend zurechtzubiegen, gewinnt man Korrektheit, zahlt aber mit weniger Nachsicht im Alltag. Beide Verhaltensweisen sind vertretbar, und beide haben ihren Preis — die eine erspart stille Fehler, die andere erspart Reibung. Welche man will, hängt daran, ob im eigenen System die Korrektheit oder die Geschmeidigkeit schwerer wiegt. Das ist keine Frage von gut und schlecht, sondern von Passung.

Wichtig ist, diese Neigungen nicht zu Dogmen zu machen. Keine der beiden ist „die für ernste Systeme" und keine „die für einfache" — beide tragen beides. Die Neigungen sagen nur, wohin man mit weniger Widerstand kommt: Ein System voll komplexer, strenger Datenlogik findet in der einen etwas mehr Rückenwind, ein einfaches, weit zu betreibendes in der anderen.

Trade-off. Die Unterschiede ernst zu nehmen bedeutet, die eigene Datenform genau anzusehen, statt einer pauschalen Vorliebe zu folgen.

Kosten. Die genaue Betrachtung kostet Zeit und ehrliche Analyse dessen, was das System an der Datenbank wirklich verlangt.

Wann wir anders entscheiden. Wo keine der besonderen Anforderungen zutrifft — der häufigste Fall —, sind die Unterschiede zu klein, um die Wahl zu tragen, und andere Kriterien (Team, Betrieb) entscheiden.

4. Wann PostgreSQL passt

PostgreSQL ist die passendere Wahl, wo die Daten reich und die Korrektheit streng sein müssen. Wenn ein System viele, ungewöhnliche oder zusammengesetzte Datentypen braucht, wenn komplexe Abfragen und Auswertungen zum Kern gehören, wenn man Wert auf eine Datenbank legt, die wenig stillschweigend annimmt und Fehler früh und deutlich meldet — dann spielt PostgreSQL seine Neigung zu Reichtum und Strenge aus. Auch wo man die Datenbank durch Erweiterungen an besondere Anforderungen anpassen will, ist ihr erweiterbarer Charakter ein echter Vorteil.

Der Preis dieser Stärke ist, dass sie eine gewisse Sorgfalt verlangt und in manchen Standardumgebungen etwas weniger selbstverständlich vorhanden ist als die verbreitetere Alternative. Wer den Reichtum nicht braucht, zahlt für ihn nur mit etwas mehr Anspruch, ohne den Gegenwert zu ernten.

Trade-off. PostgreSQLs Reichtum kauft Ausdruckskraft und Strenge mit etwas höherem Anspruch an Sorgfalt und Betrieb.

Kosten. Die Fülle an Möglichkeiten will beherrscht werden; ein Team, das sie nicht nutzt, trägt Komplexität, die es nicht braucht.

Wann wir anders entscheiden. Wo die Daten einfach und die Abfragen gängig sind, bringt der Reichtum keinen Gegenwert — dann ist die einfachere, verbreitetere Wahl die passendere.

5. Wann MySQL passt

MySQL ist die passendere Wahl, wo Einfachheit und Verbreitung zählen. Wenn die Datenform geradlinig ist, die Abfragen gängig, die Anforderungen an ungewöhnliche Datentypen gering — und wenn das Team oder die Betriebsumgebung mit MySQL vertraut ist —, dann ist ihre Neigung zu Schlichtheit und Allgegenwart ein realer Vorteil. Für viele verbreitete Anwendungen ist sie der Weg des geringsten Widerstands: gut verstanden, überall verfügbar, mit einem riesigen Fundus an Erfahrung für die üblichen Muster.

Der Preis ist das Spiegelbild von PostgreSQLs Stärke: Wo man Reichtum und Strenge doch braucht, muss man sie mit mehr Aufwand nachbilden, und die historisch pragmatischere Haltung verlangt, dass man selbst genauer auf Korrektheit achtet, wo die Datenbank sie nicht erzwingt.

Trade-off. MySQLs Einfachheit kauft geringen Widerstand und breite Vertrautheit mit weniger eingebautem Reichtum und Strenge.

Kosten. Wo doch strenge Korrektheit oder ungewöhnliche Typen gebraucht werden, trägt man den Aufwand, sie außerhalb der Datenbank sicherzustellen.

Wann wir anders entscheiden. Sobald reiche Typen, komplexe Auswertungen oder strenge Korrektheit zum Kern gehören, überwiegt der Aufwand des Nachbildens den Vorteil der Einfachheit — dann passt die reichere Wahl besser.

6. Das Kriterium: Datenform und Team

Wenn beide reif sind und die Unterschiede an den Rändern liegen, worauf gründet man die Entscheidung? Auf zwei Dinge: die Form der Daten und das Team, das die Datenbank betreibt. Die Datenform sagt, welche Neigung mehr Rückenwind gibt — reich und streng oder einfach und verbreitet. Das Team sagt, welche Datenbank verlässlich betrieben wird, denn eine Datenbank ist nur so gut wie der Betrieb, der sie trägt. Eine theoretisch etwas passendere Datenbank, die niemand sicher bedient, ist die schlechtere Wahl gegenüber der vertrauten, die das Team im Schlaf beherrscht.

Schema: Der weitaus größte Teil ist gemeinsames Fundament. Die Unterschiede sitzen oben, an den Rändern — sie entscheiden nur, wenn das System sie wirklich berührt.

Schema: Nicht besser oder schlechter, sondern Rückenwind. Nur an den Enden des Bandes wird die Neigung zum Ausschlag; in der breiten Mitte tragen beide.

Der Betrieb ist dabei mehr als Vertrautheit im Alltag. Eine Datenbank verlangt über die Jahre Sicherungen, die man im Ernstfall auch zurückspielen kann, ein Verständnis ihres Verhaltens unter Last, einen Plan für Ausfälle und für das Einspielen von Änderungen ohne Stillstand. Ein Team, das diese Handgriffe für eine der beiden beherrscht — geprüfte Sicherungen, verstandene Grenzen, eingeübte Reaktionen —, trägt sie durch das Jahrzehnt; ein Team, das sie für die theoretisch passendere erst lernen müsste, trägt ein Risiko, das keine Datenbankeigenschaft aufwiegt. Deshalb ist die betriebliche Reife oft das stärkste Argument von allen: Sie entscheidet nicht, welche Datenbank die bessere ist, sondern welche in genau diesen Händen die verlässlichere sein wird.

Die Langlebigkeit verschärft das Kriterium nicht, sie entspannt es: Weil beide ein Jahrzehnt tragen, muss man die Wahl nicht als Schicksalsentscheidung führen. Man wählt die, die zur Datenform passt und die das Team betreiben kann — und richtet die freigewordene Energie auf das Datenmodell, die Indizierung und die Migrationsdisziplin, die über die Jahre ungleich mehr entscheiden als der Name der Datenbank.

Trade-off. Nach Datenform und Team zu entscheiden bedeutet, die eigene Lage ehrlich zu benennen, statt sich hinter einer allgemeinen Empfehlung zu verstecken.

Kosten. Das Kriterium verlangt zwei ehrliche Einschätzungen — der Daten und des Teams —, die man leicht beschönigt.

Wann wir anders entscheiden. Wo eine harte äußere Vorgabe besteht — eine vorhandene Betriebsumgebung, eine geforderte Kompatibilität —, tritt das Kriterium zurück, und man folgt der Vorgabe.

7. Bindung und Umkehrbarkeit

So reversibel die Wahl im Grundsatz ist — beide sprechen SQL —, so leicht bindet man sich in der Praxis fester, als nötig. Jede datenbankspezifische Besonderheit, die man nutzt, macht einen späteren Wechsel teurer. Das ist kein Grund, Besonderheiten zu meiden — sie sind oft genau der Vorteil, für den man die Datenbank gewählt hat —, aber ein Grund, bewusst zu entscheiden: Nutze ich hier eine Besonderheit, weil sie einen echten Gewinn bringt, oder aus Gewohnheit, wo Standard-SQL genügt hätte?

Die Haltung ist dieselbe wie bei jeder folgenreichen Wahl: das Umkehrbare billig halten, wo es leicht ist, und sich nur dort binden, wo der Gewinn den Preis wert ist. Wer den Kern seiner Datenzugriffe in Standard-SQL hält und die Besonderheiten bewusst und lokal einsetzt, behält die Freiheit, die Datenbank eines Tages zu wechseln, ohne das halbe System anzufassen — ohne auf die Vorteile zu verzichten, wo sie zählen.

In der Praxis ist ein Wechsel selten, und das ist kein Widerspruch: Gerade weil man die Wahl umkehrbar hält, muss man sie fast nie umkehren. Die Umkehrbarkeit ist nicht dazu da, ständig gewechselt zu werden, sondern um nicht gefangen zu sein, falls sich die Anforderungen grundlegend verschieben. Wer sie wahrt, entscheidet die Datenbankfrage ohne die Angst, sich für immer festzulegen — und diese Gelassenheit ist selbst ein Wert, weil sie die Entscheidung von ihrer falschen Schwere befreit.

Trade-off. Sich an Besonderheiten zu binden kauft ihren Vorteil mit einem teureren späteren Wechsel — bewusst getroffen, ist das ein guter Tausch.

Kosten. Umkehrbarkeit zu wahren verlangt Disziplin: den Zugriff so zu gestalten, dass die Besonderheiten lokal bleiben und nicht das ganze System durchdringen.

Wann wir anders entscheiden. Wo ein Wechsel praktisch ausgeschlossen ist und eine Besonderheit großen Gewinn bringt, nutzt man sie ohne Zurückhaltung; die Vorsicht gilt dort, wo ein Wechsel denkbar bleibt.

8. Typische Fehler

Die wiederkehrenden Muster, an denen die Datenbankwahl scheitert — fast alle sind Varianten davon, die falsche Frage zu stellen:

• Die Wahl als Lagerkampf führen, statt sie an der Form der eigenen Daten zu entscheiden.
• Energie in das Ranking der Datenbanken stecken, die dem Datenmodell und der Indizierung fehlt.
• Eine theoretisch passendere Datenbank wählen, die das Team nicht sicher betreibt.
• Den Reichtum der einen kaufen, ohne ihn zu nutzen — Komplexität ohne Gegenwert tragen.
• Die Einfachheit der anderen wählen und dann strenge Korrektheit erwarten, die man selbst hätte sichern müssen.
• Sich unnötig an Besonderheiten binden, wo Standard-SQL genügt hätte, und einen späteren Wechsel teuer machen.
• Die Reife beider übersehen und die Wahl als Schicksalsentscheidung überhöhen, die sie selten ist.

9. Entscheidungs-Checkliste

Vor der Wahl zwischen den beiden der Reihe nach zu klären:

• Datenform? Sind die Daten reich und streng (eher PostgreSQL) oder einfach und gängig (eher MySQL)?
• Besondere Anforderung? Hängt etwas Wesentliches genau an einem der Unterschiede — oder liegt alles im gemeinsamen Fundament?
• Team und Betrieb? Welche Datenbank betreibt das Team verlässlich, und welche ist in der Umgebung schon zu Hause?
• Reichtum genutzt? Falls die reichere Wahl: Nutze ich ihre Stärken wirklich — oder trage ich nur ihre Komplexität?
• Korrektheit gesichert? Falls die einfachere Wahl: Stelle ich strenge Korrektheit dort sicher, wo die Datenbank sie nicht erzwingt?
• Bindung bewusst? Nutze ich Besonderheiten aus echtem Gewinn — oder aus Gewohnheit, wo Standard-SQL genügt?
• Energie richtig? Fließt die Aufmerksamkeit ins Datenmodell und die Migrationsdisziplin, nicht in den Namensstreit?

Wer diese Fragen beantworten kann, hat nach der Sache entschieden — und erkannt, dass die Wahl selten das ist, worauf es wirklich ankommt.

FAQ

Welche ist die bessere Datenbank? Keine allgemein. Beide sind reif, relational und tragen ein System über Jahre. Die nützliche Frage ist nicht „welche ist besser", sondern „welche passt zur Form meiner Daten und zu meinem Team". Für die meisten Systeme wäre jede von beiden eine gute Wahl.

Ist PostgreSQL nicht die „ernstere" Datenbank? Sie neigt zu Reichtum und Strenge, aber „ernst" sind beide. MySQL trägt große, ernste Systeme ebenso. Die Neigung sagt, wohin man mit weniger Widerstand kommt, nicht, welche für seriöse Software taugt — das tun beide.

Spielt die Wahl überhaupt eine große Rolle? Seltener, als der Streit vermuten lässt. Über die Jahre entscheiden Datenmodell, Indizierung und die Disziplin der Migrationen ungleich mehr als der Name der Datenbank. Die Wahl zwischen zwei reifen Optionen ist wichtig genug, um bewusst getroffen zu werden, aber selten das, was ein System trägt oder scheitern lässt.

Was, wenn wir uns später umentscheiden wollen? Im Grundsatz geht das, weil beide SQL sprechen; in der Praxis hängt der Preis daran, wie viele datenbankspezifische Besonderheiten man genutzt hat. Wer den Kern in Standard-SQL hält und Besonderheiten bewusst und lokal einsetzt, behält die Freiheit zum Wechsel, ohne auf Vorteile zu verzichten, wo sie zählen.

Sollten wir nach dem entscheiden, was das Team kennt? Sehr oft ja. Eine Datenbank ist nur so gut wie ihr Betrieb, und die vertraute, sicher betriebene schlägt die theoretisch etwas passendere, die niemand beherrscht — es sei denn, eine besondere Anforderung hängt genau an einem Unterschied.

Was ist der teuerste Fehler bei dieser Wahl? Nicht die falsche Datenbank, sondern die vergeudete Aufmerksamkeit. Wer Wochen in den Namensstreit steckt und dann das Datenmodell nachlässig entwirft, hat an der einzig folgenreichen Stelle gespart. Fast ebenso teuer ist die Unentschlossenheit: mitten im Projekt zu wechseln oder beide Optionen offenzuhalten kostet mehr als jede der beiden Datenbanken je gekostet hätte. Entscheiden, sauber modellieren, weitermachen — das ist der Weg.

Weiterführend

• Zero-Downtime-Datenbankmigrationen — was über die Jahre mehr entscheidet als die Wahl der Datenbank: die Disziplin, ihr Schema zu ändern.
• Als Schema und Modell auseinanderliefen — warum die Sorgfalt am Datenmodell wichtiger ist als der Name der Datenbank.
• PostgreSQL: JSONB vs. Tabellen — eine konkrete Modellierungsentscheidung innerhalb der Datenbank.
• Ausgereifte Technik vor Neuheit — warum die Reife beider der eigentliche Gewinn ist.

Grundlage ist die Batunet Engineering Method: nach der Form der Daten und dem Team entscheiden, die Wahl umkehrbar halten, die Energie ins Datenmodell lenken.

Abschließendes Engineering-Prinzip

Die reifste Antwort auf „PostgreSQL oder MySQL" ist, die Frage in ihre richtige Größe zu rücken. Sie ist wichtig genug, um bewusst entschieden zu werden, und unwichtig genug, um sie nicht zum Glaubenskrieg zu erheben. Beide Datenbanken haben bewiesen, dass sie tragen; keine wird ein gut modelliertes System scheitern lassen, und keine wird ein schlecht modelliertes retten. Wer das verstanden hat, wählt in Minuten, was andere in Wochen bestreiten — nach der Form der Daten, nach dem Team, nach der besonderen Anforderung, falls es eine gibt — und wendet sich dann dem zu, worauf es wirklich ankommt: dem Modell, den Indizes, der Disziplin, mit der man das Schema über die Jahre ändert. Dort, nicht im Namen der Datenbank, entscheidet sich die Langlebigkeit.

Die Wahl zwischen zwei reifen Datenbanken ist selten der Grund, warum ein System trägt oder scheitert. Das entscheidet sich am Datenmodell — und das gehört keiner der beiden, sondern dem, der es entwirft.