MySQL oder PostgreSQL: Welche Datenbank für Ihre Anwendung?
MySQL oder PostgreSQL: Für eine typische Webanwendung mit Kunden, Aufträgen und Rechnungen reichen beide. PostgreSQL ist die bessere Wahl, wenn Sie JSON-Daten, Geodaten, strenge Datenregeln oder eine Trennung von Mandanten in der Datenbank brauchen; MySQL und MariaDB punkten, wo vorhandene Systeme, Hoster und Fachleute schon darauf eingestellt sind.
Die Wahl der Datenbank fällt oft nebenbei, weil der Hoster eine vorgibt oder das letzte Projekt sie genutzt hat. Das ist nicht schlimm, solange die Anwendung im Rahmen bleibt. Teuer wird es, wenn nach zwei Jahren eine Anforderung kommt, die die gewählte Datenbank schlecht abbildet, und der Wechsel dann jede Abfrage berührt. Beide Systeme sind quelloffen, ausgereift und laufen auf jedem gängigen Linux-Server. Der Unterschied liegt in den Details, die erst im dritten Projektjahr auffallen.
Entscheidung
MySQL oder PostgreSQL im neuen Projekt
Bevor es in die Details geht, unsere Empfehlung in drei Sätzen. Für eine neue Anwendung mit eigenem Datenmodell, wechselnden Zusatzfeldern oder mehreren Mandanten raten wir zu PostgreSQL, weil es bei JSON, Datenregeln und Erweiterungen mehr Spielraum lässt. Wer ein bestehendes System auf MySQL oder MariaDB betreibt, braucht für einen Wechsel einen konkreten Grund, nicht nur einen Trend. Und wer Daten mit Shopsystemen, Warenwirtschaft oder Branchensoftware teilt, die nur MySQL unterstützen, bleibt dort. Die wichtigsten Unterschiede auf einen Blick, die Abschnitte darunter erklären sie:
| MySQL und MariaDB | PostgreSQL | |
|---|---|---|
| JSON | MySQL mit eigenem Binärformat, MariaDB als Textspalte | Datentyp jsonb, durchsuchbar mit GIN-Indizes |
| Datenregeln in der Datenbank | Prüfbedingungen, Fremdschlüssel | Zusätzlich Bereichstypen, Ausschlussregeln, eigene Datentypen |
| Strukturänderungen | Fast jede Änderung löst einen impliziten Commit aus | Laufen in einer Transaktion und lassen sich zurückrollen |
| Trennung von Mandanten | In der Anwendung | Zusätzlich Schemas und Row Level Security in der Datenbank |
| Groß- und Kleinschreibung | Übliche Sortierregeln vergleichen ohne Unterschied | Vergleiche unterscheiden Groß- und Kleinschreibung standardmäßig |
| Verbreitung | Standard bei WordPress, Shopware, Magento und vielen Hostern | Verbreitet bei Anwendungen mit eigenem Datenmodell |
| Erweiterungen | Kein vergleichbares System für neue Datentypen und Indexarten | PostGIS, pgvector, TimescaleDB und viele mehr |
Gemeinsamkeiten
Wofür beide genügen
Für die meisten Geschäftsanwendungen sind die Unterschiede kleiner als ihr Ruf. Beide Systeme beherrschen:
Transaktionen und Fremdschlüssel: Eine Bestellung mit Positionen wird ganz oder gar nicht gespeichert, Datensätze verweisen verlässlich aufeinander. Bei MySQL gilt das für die Standard-Speicher-Engine InnoDB.
Replikation: Eine zweite Instanz übernimmt Lesezugriffe oder springt bei einem Ausfall ein. Laravel trennt Lese- und Schreibverbindungen auf Wunsch selbst.
JSON-Spalten: Zusatzangaben, die nicht in jede Tabelle passen, lassen sich als JSON speichern und abfragen.
Volltextsuche für Suchfelder in Verwaltungsoberflächen, ohne zusätzlichen Suchdienst.
Laravel unterstützt beide offiziell, laut Dokumentation MySQL ab 5.7, MariaDB ab 10.3 und PostgreSQL ab 10.0. Wer Eloquent und den Query Builder nutzt und auf rohes SQL verzichtet, schreibt Code, der auf beiden läuft. Bei Lastfragen zählt nach unserer Erfahrung meist mehr, ob die richtigen Indizes gesetzt sind, als welches System darunter liegt, weil eine fehlende Index-Spalte eine Abfrage um Größenordnungen verlangsamt, der Wechsel der Datenbank aber nicht. Wie das in PostgreSQL aussieht, zeigt der Beitrag PostgreSQL-Indexing für Laravel-Apps.
Stärken
Wo PostgreSQL Vorteile hat
PostgreSQL ist strenger und vielseitiger. Das zeigt sich an vier Stellen.
JSON als echter Datentyp: Der Typ jsonb speichert JSON in zerlegter Form und lässt sich mit GIN-Indizes durchsuchen. Damit taugt PostgreSQL für Daten, deren Felder je Kunde oder Produkt verschieden sind.
Datenregeln in der Datenbank: Prüfbedingungen, eigene Datentypen, Bereichstypen für Zeiträume und Ausschlussregeln, etwa „kein Raum doppelt gebucht“, hält die Datenbank selbst ein, auch wenn ein Import am Code vorbeischreibt. Wie oft solche Zeiträume in Geschäftsanwendungen stecken, zeigt imm smartControl, eine Hausverwaltungs-Software, die wir seit August 2021 entwickeln: Sie bildet Mietverhältnisse und Vertragszustände über die Zeit ab. Zwei Mietverhältnisse derselben Wohnung dürfen sich nicht überschneiden, und genau diese Regel kann PostgreSQL mit einer Ausschlussregel selbst durchsetzen.
Erweiterungen: PostGIS für Geodaten, pgvector für die Ähnlichkeitssuche mit KI-Vektoren, TimescaleDB für Zeitreihen. Vieles, wofür sonst ein zweiter Dienst nötig wäre, läuft in derselben Datenbank.
Zeilenbasierte Sicherheit: Mit Row Level Security filtert die Datenbank selbst nach Mandant.
Bei einem fehlgeschlagenen Update zeigt sich ein weiterer Unterschied. In PostgreSQL laufen auch Änderungen an der Tabellenstruktur in einer Transaktion. Bricht eine Migration mit fünf Schritten beim vierten ab, ist die Datenbank wieder im alten Zustand. In MySQL und MariaDB löst fast jede Strukturänderung einen impliziten Commit aus, die Laravel-Dokumentation warnt ausdrücklich davor. Die ersten drei Schritte bleiben dann bestehen, und jemand muss die halbe Migration von Hand zurückbauen, bevor die Auslieferung wiederholt werden kann.
Verbreitung
Wo MySQL und MariaDB punkten
MySQL ist im Web am weitesten verbreitet. WordPress, Shopware, Magento und viele Shop- und Branchensysteme setzen darauf, und fast jeder Hoster und jeder PHP-Entwickler kennt es. Wenn Ihre Anwendung Daten mit einem solchen System teilt, spart dieselbe Datenbank Übersetzungsarbeit.
Versionsstand im Juni 2026
PostgreSQL bringt etwa einmal im Jahr eine Hauptversion und pflegt jede fünf Jahre lang. Aktuell ist Version 18 vom 25.09.2025, Version 14 erhält am 12.11.2026 ihr letztes Update.
Oracle unterscheidet bei MySQL zwei Linien: LTS-Versionen, die acht Jahre gepflegt werden und keine Verhaltensänderungen mehr bekommen, und Innovation-Versionen mit neuen Funktionen, die nur bis zur nächsten Innovation-Version gepflegt werden. Für Geschäftsanwendungen gehört eine LTS-Version auf den Server, weil Updates innerhalb der Linie das Verhalten nicht ändern und die Pflege acht Jahre läuft. MySQL 8.0 hat im April 2026 mit Version 8.0.46 sein Lebensende erreicht. Gepflegt werden 8.4 LTS und seit 21.04.2026 die neue Linie 9.7 LTS. Ein Sprung über eine LTS-Linie hinweg ist laut Oracle nicht vorgesehen, von 8.0 geht es also zuerst auf 8.4.
MariaDB ist 2009 als Abspaltung von MySQL entstanden und wird von der MariaDB Foundation gepflegt. Die Systeme sind sich nah, aber nicht mehr gleich. Der Typ JSON etwa ist in MariaDB nur ein anderer Name für eine lange Textspalte, in MySQL ein eigenes Binärformat. Aktuelle LTS-Versionen sind 11.4 (gepflegt bis 2029), 11.8 (bis 2028) und 12.3 vom 28.05.2026, die wie schon 11.8 nur noch drei Jahre gepflegt wird, also bis Mitte 2029.
Debian liefert übrigens kein MySQL von Oracle aus. Das Paket für den „Standard-MySQL-Server“ installiert unter Debian 13 MariaDB 11.8. Wer im Lastenheft „MySQL 8.4“ liest, sollte deshalb prüfen, ob wirklich MySQL gemeint ist, und welche Version auf dem Server tatsächlich läuft.
Wechsel
Wechsel später: Aufwand und Risiken
Ein Wechsel zwischen den Systemen ist machbar, aber selten nur ein Export und Import. Die Daten selbst lassen sich mit Werkzeugen wie pgloader übertragen, das Tabellen, Indizes und Daten von MySQL nach PostgreSQL überführt. Die Arbeit steckt in der Anwendung:
Groß- und Kleinschreibung: Die üblichen MySQL-Sortierregeln vergleichen ohne Rücksicht auf Groß- und Kleinschreibung. Eine Suche nach „Mueller@beispiel.de“ findet dort auch „mueller@beispiel.de“, in PostgreSQL nicht. Anmeldungen, Dublettenprüfungen und Suchfelder verhalten sich nach dem Wechsel anders, ohne dass ein Test rot wird, sofern niemand genau diesen Fall geprüft hat.
Rohes SQL: Jede Abfrage, die am Query Builder vorbeigeschrieben wurde, muss einzeln geprüft werden, etwa Datums- und Textfunktionen oder Spaltennamen in den schrägen Anführungszeichen von MySQL, die PostgreSQL nicht versteht.
Zahlen und Wahrheitswerte: MySQL speichert Wahrheitswerte als kleine Zahl, PostgreSQL als echten Typ. Berichte und Exporte, die mit 0 und 1 rechnen, brauchen Anpassungen.
Betrieb: Backups, Monitoring, Benutzerrechte und Wartungsaufgaben unterscheiden sich und müssen neu eingerichtet werden.
Unsere Schätzung für eine Laravel-Anwendung, die fast nur Eloquent nutzt und gute Tests hat: 3 bis 8 Personentage für Umstellung und Prüfung. Bei viel rohem SQL, gespeicherten Prozeduren oder angebundenen Fremdsystemen werden daraus schnell mehrere Wochen. Deshalb gehört die Wahl an den Anfang eines Projekts, zusammen mit Datenmodell und Backup-Konzept, wie wir es bei unseren Datenbank-Systemen beschreiben. Wie wir Anwendung und Datenbank gemeinsam auf Servern in Deutschland betreiben, steht auf der Seite Hosting.
Datenbank passend zum Vorhaben wählen
Wir schauen uns Ihre Daten, Abfragen und angebundenen Systeme an und empfehlen das System, das auch in fünf Jahren noch passt.
Kurz beantwortet
Häufige Fragen
-
Pauschal nicht. Bei den üblichen Lese- und Schreibzugriffen einer Webanwendung entscheiden Indizes, Abfragen und Serverkonfiguration über die Geschwindigkeit, nicht der Name der Datenbank. Bei JSON-Suchen hat PostgreSQL mit jsonb und GIN-Indizes Werkzeuge, die MySQL so nicht bietet. Belastbare Aussagen für Ihren Fall liefert nur ein Lasttest mit Ihren Daten und Ihren Abfragen.
-
MariaDB ist eine Abspaltung von MySQL aus dem Jahr 2009 und wird von einer eigenen Stiftung gepflegt. Für die meisten Laravel-Anwendungen sind beide austauschbar, in Details wie JSON, Systemtabellen und neuen Funktionen gehen sie aber getrennte Wege. Ein Wechsel zwischen beiden sollte deshalb wie ein Update getestet werden.
-
Laravel unterstützt MySQL, MariaDB und PostgreSQL offiziell, dazu SQLite und SQL Server. Solange der Code Eloquent und den Query Builder nutzt, bleibt er weitgehend unabhängig von der Datenbank. Datenbankspezifische Funktionen wie jsonb-Indizes nutzen Sie gezielt dort, wo sie sich auszahlen.
-
Für interne Werkzeuge mit wenigen gleichzeitigen Nutzern und für Tests ist SQLite eine gute Wahl, weil die ganze Datenbank in einer Datei liegt. Sobald mehrere Server, viele gleichzeitige Schreibzugriffe oder Replikation nötig werden, ist ein Datenbankserver die bessere Grundlage.
Nachweise
Quellen und Stand
Stand: 18.06.2026, ergänzt am 02.11.2026 um das Supportende von MariaDB 12.3. Versionen und Supportzeiträume laut den Projektseiten von PostgreSQL, MySQL und MariaDB sowie den Paketlisten von Debian.
Artikel teilen