PostgreSQL vs MySQL (2026): Der ehrliche Vergleich mit eigenem Benchmark

PostgreSQL vs MySQL ist die erste große Architekturentscheidung in fast jedem Webprojekt, und sie wird meistens aus dem Bauch heraus getroffen. Die kurze Antwort vorweg: Für ein neues Projekt ohne Vorgaben nehmen wir PostgreSQL. Es ist strenger mit deinen Daten, kann mehr, und es war in unserem eigenen Test bei Auswertungen drei- bis siebenmal schneller. MySQL bleibt die richtige Wahl, wenn deine Software es verlangt (WordPress, Shopware, Magento und viele PHP-Anwendungen), wenn dein Hoster nur MySQL anbietet oder wenn dein Team MySQL seit Jahren im Schlaf betreibt.

Damit das nicht nur eine Meinung ist, haben wir am 10. Oktober 2026 beide Datenbanken auf demselben Server mit exakt denselben Daten gegeneinander laufen lassen: PostgreSQL 17.11 und MySQL 8.4.11 (die aktuelle LTS-Linie, die in den meisten Linux-Distributionen und Docker-Setups steckt), jeweils im offiziellen Docker-Image, mit Standardkonfiguration und auf 2 CPU-Kerne und 2 GB RAM begrenzt. Drei Ergebnisse vorweg:

1. Direkt nach dem Start belegte PostgreSQL 24 MB RAM, MySQL 424 MB. Auf einem kleinen VPS ist das ein echter Unterschied.

2. Eine Auswertung über 2 Millionen Bestellungen (Gruppieren nach Stadt) brauchte bei PostgreSQL rund 105 ms, bei MySQL rund 670 ms. Ein Join über zwei Tabellen: rund 200 ms gegenüber 1,4 Sekunden.

3. Bei der Frage „liefere mir genau diesen einen Datensatz über einen Index“ waren beide gleich schnell, nämlich ungefähr eine Millisekunde. Für die typische Webseite, die einzelne Datensätze liest, ist der Geschwindigkeitsunterschied praktisch egal. Er zeigt sich erst bei Auswertungen.

PostgreSQL vs MySQL: Was die beiden Datenbanken gemeinsam haben

Bevor es um Unterschiede geht: Beide sind relationale Datenbanken. Du legst Tabellen mit Spalten an, verbindest sie über Schlüssel, und du fragst sie mit SQL ab. Ein SELECT name FROM kunden WHERE stadt = 'Berlin' funktioniert in beiden identisch. Beide sind Open Source und kostenlos nutzbar, beide laufen auf jedem Linux-Server, beide beherrschen Transaktionen, Indizes, Fremdschlüssel, Replikation und JSON-Spalten. Wer die Grundlagen von SQL in der einen Datenbank gelernt hat, findet sich in der anderen in ein paar Stunden zurecht.

Die Unterschiede liegen also nicht im „ob“, sondern im „wie“: wie streng sie mit falschen Daten umgehen, wie sie intern arbeiten, wie viel Speicher sie brauchen, was sie über den Standard hinaus können und wer hinter ihnen steht.

Wer hinter PostgreSQL steht

PostgreSQL entstand ab 1986 als Forschungsprojekt „Postgres“ an der University of California in Berkeley, geleitet von Michael Stonebraker. Seit den späten 1990ern heißt es PostgreSQL und wird von der PostgreSQL Global Development Group entwickelt, einer Gemeinschaft ohne einzelnen Eigentümer. Mitarbeitende von vielen Firmen (unter anderem EDB, Microsoft, Amazon, Crunchy Data) arbeiten daran mit, aber keine Firma besitzt PostgreSQL. Die Lizenz ist die sehr freizügige „PostgreSQL License“, vergleichbar mit MIT oder BSD: Du darfst den Code nutzen, verändern und auch in geschlossene Produkte einbauen.

Pro Jahr erscheint eine Hauptversion, jede wird fünf Jahre lang mit Fehlerbehebungen versorgt. Aktuell stabil ist PostgreSQL 18 (erschienen im September 2025). PostgreSQL 19 ist laut offizieller Roadmap für Oktober 2026 geplant, die vierte Beta erschien am 24. September 2026. Wir haben bewusst mit Version 17 getestet, weil das die Version ist, die derzeit in den meisten produktiven Setups und Hosting-Angeboten läuft.

Wer hinter MySQL steht

MySQL stammt von 1995, geschrieben vom schwedischen Unternehmen MySQL AB (Mitgründer: Michael „Monty“ Widenius, nach dessen Tochter My die Datenbank benannt ist). 2008 kaufte Sun Microsystems MySQL, 2010 übernahm Oracle Sun und damit auch MySQL. Seitdem gehört MySQL einer einzelnen Firma. Es gibt eine kostenlose Community Edition unter der GPLv2 und kommerzielle Editionen mit zusätzlichen Funktionen.

Aus Sorge vor genau dieser Übernahme hat Widenius 2009 den Fork MariaDB gestartet (benannt nach seiner zweiten Tochter Maria). MariaDB ist zu großen Teilen kompatibel mit MySQL, hat sich aber über die Jahre in Details auseinanderentwickelt. Viele Linux-Distributionen installieren bei apt install mysql-server inzwischen eigentlich MariaDB, was für Einsteiger regelmäßig für Verwirrung sorgt. Auf unserem eigenen Server zeigt mysql --version zum Beispiel MariaDB 10.11.14, obwohl der Befehl mysql heißt.

Bei MySQL selbst hat sich 2026 einiges getan: MySQL 8.0 ist seit April 2026 am Ende seiner Unterstützung, die aktuellen Langzeitversionen sind 8.4 LTS und 9.7 LTS (veröffentlicht im April 2026, die erste neue LTS seit 8.4). Für künftige Versionen hat Oracle auf Kalenderversionen umgestellt: MySQL 26.7 steht für die Version vom Juli 2026. Wer noch auf 8.0 läuft, sollte sein Upgrade nicht mehr aufschieben.

Kompakte Einführung von IBM Technology (englisch, Dezember 2022). Die Grundunterschiede gelten unverändert, Versionsnummern im Video sind älter.

Die Unterschiede auf einen Blick

Laut der Stack Overflow Developer Survey 2025 ist PostgreSQL inzwischen die meistgenutzte Datenbank unter professionellen Entwicklerinnen und Entwicklern, mit über 55 Prozent und deutlichem Abstand vor MySQL. Das sagt nichts darüber, was für dein Projekt besser ist, aber es erklärt, warum neue Frameworks und Plattformen fast immer zuerst für PostgreSQL gebaut werden.

Unser Benchmark: So haben wir gemessen

Fast jeder Artikel zu PostgreSQL vs MySQL zitiert irgendwelche Benchmarks von irgendwem. Wir wollten wissen, wie es auf einem normalen Server aussieht, wie ihn kleine Firmen und Selbstständige wirklich mieten. Deshalb:

• Hardware: unser eigener Server mit AMD-EPYC-Prozessor (Genoa-Generation), 12 vCPU. Jeder Datenbank-Container war auf 2 Kerne und 2 GB RAM begrenzt (docker run --cpus 2 --memory 2g). Das entspricht ungefähr einem kleinen Cloud-Server, wie wir ihn im Hetzner-vs-netcup-Vergleich beschrieben haben.
• Software: offizielle Docker-Images postgres:17 (17.11) und mysql:8.4 (8.4.11), Docker 29.2.1. Keine Konfiguration angepasst. Das ist absichtlich: Die meisten Datenbanken laufen in der Praxis mit Standardwerten, weil niemand sie tunt.
• Daten: zwei Tabellen, generiert mit festem Zufalls-Seed, also in beiden Datenbanken identisch: 100.000 Kunden und 2.000.000 Bestellungen (Kunden-ID, Stadt, Betrag, Datum). Ein Index auf customer_id.
• Wiederholungen: jede Abfrage dreimal hintereinander, wir nennen die Spanne. Daten lagen nach dem ersten Lauf im Cache, gemessen ist also der „warme“ Zustand, der für eine laufende Anwendung typisch ist.

Wichtig für die Einordnung: Das ist kein Labor-Benchmark, sondern ein Praxis-Test auf geteilter Hardware. Die Zahlen schwanken um einige Prozent, und mit Tuning lässt sich bei beiden Datenbanken viel herausholen. Die Größenordnungen sind aber eindeutig und wiederholbar.

Ergebnis 1: Daten importieren

Beide Datenbanken haben einen schnellen Massenimport: PostgreSQL mit COPY, MySQL mit LOAD DATA INFILE. Die CSV-Datei mit 2 Millionen Bestellungen war 77 MB groß.

PostgreSQL importiert etwa doppelt so schnell. Dafür braucht es mehr Platz: 172 MB gegenüber 120 MB für dieselben Daten. Das liegt am Aufbau: PostgreSQL speichert an jeder Zeile einen Kopf von 23 Byte mit Versionsinformationen (dazu gleich mehr bei MVCC), MySQL organisiert die Tabelle als Baum um den Primärschlüssel herum und kommt mit weniger Verwaltungsdaten pro Zeile aus. Bei 2 Millionen Zeilen sind das 52 MB, bei 2 Milliarden Zeilen wären es 52 GB. Für die Planung von Festplatte und Backups ist das relevant.

Ergebnis 2: Auswertungen (die Überraschung)

Zwei typische Abfragen, wie sie in jedem Admin-Dashboard vorkommen:

Abfrage A: Anzahl und Durchschnittsbetrag pro Stadt über alle 2 Millionen Bestellungen:

SELECT city, count(*), round(avg(amount), 2)
FROM orders GROUP BY city ORDER BY 2 DESC LIMIT 3;

Abfrage B: Umsatz pro Kundenstadt seit Juni, mit Join auf die Kundentabelle:

SELECT c.city, sum(o.amount)
FROM orders o JOIN customers c ON c.id = o.customer_id
WHERE o.created >= '2026-06-01'
GROUP BY c.city ORDER BY 2 DESC LIMIT 3;

Beide Datenbanken lieferten exakt dieselben Ergebnisse (Hamburg 250.949 Bestellungen, Durchschnitt 250,50 €), wir haben also wirklich dasselbe gemessen.

Der Hauptgrund für den Abstand ist sichtbar, wenn man PostgreSQL mit EXPLAIN fragt, was es tut: Es plant „Workers Planned: 2“, verteilt die Abfrage also auf beide verfügbaren Kerne. MySQL führt eine einzelne Abfrage grundsätzlich auf einem Kern aus. Damit der Vergleich fair bleibt, haben wir die Parallelisierung in PostgreSQL abgeschaltet (SET max_parallel_workers_per_gather = 0). Auch dann ist PostgreSQL noch 2,3- bis 4-mal schneller. Für Abfrage B kommt dazu, dass PostgreSQL einen Hash Join verwendet, während MySQL bei dieser Art Join länger braucht.

Was heißt das praktisch? Wenn dein Projekt Berichte, Statistiken, Filter über große Datenmengen oder irgendeine Form von Analyse enthält, macht PostgreSQL einen spürbaren Unterschied. Eine Sekunde gegenüber 200 Millisekunden merkt jeder, der auf ein Dashboard wartet.

Ergebnis 3: Einzelne Datensätze lesen (Gleichstand)

Das ist der Normalfall jeder Webanwendung: „Zeig mir die Bestellungen von Kunde 4242.“ Mit Index auf der Spalte war das in beiden Datenbanken in rund einer Millisekunde erledigt. MySQL meldete sogar „0,00 sec“, weil der eingebaute Zähler so kleine Zeiten nicht mehr auflöst.

Spannender wird es unter Last. Wir haben viele parallele Clients dieselbe Art Abfrage stellen lassen, jeweils über eine normale TCP-Verbindung von außerhalb des Containers:

Hier gibt es eine Einschränkung, die wir offen sagen müssen: Die beiden Datenbanken wurden mit unterschiedlichen Werkzeugen belastet, PostgreSQL mit seinem eigenen pgbench, MySQL mit mariadb-slap (MySQL 8.4 liefert sein mysqlslap im Docker-Image nicht mehr mit). Die Werkzeuge arbeiten ähnlich, aber nicht identisch. Die Tabelle zeigt deshalb eine Tendenz, keinen exakten Sieger. Die Tendenz: Bei einzelnen Clients ist PostgreSQL deutlich schneller, unter Volllast liegen beide nah beieinander. Bei 2 Kernen ist die Hardware mit rund 35.000 bis 39.000 Abfragen pro Sekunde einfach ausgereizt, egal welche Datenbank.

Für die allermeisten Webseiten ist das eine beruhigende Nachricht: Ein Onlineshop mit ein paar tausend Besuchern am Tag erzeugt einen Bruchteil davon. Keine der beiden Datenbanken wird dein Flaschenhals sein, solange die Indizes stimmen.

Ergebnis 4: Schreiben mit voller Datensicherheit

5.000 einzelne UPDATE-Befehle, jeder in seiner eigenen Transaktion (so, wie eine Webanwendung typischerweise schreibt: ein Klick, eine Änderung):

Beide liefen mit voller Absicherung: Jede bestätigte Änderung wird sofort auf die Platte geschrieben (fsync = on bei PostgreSQL, innodb_flush_log_at_trx_commit = 1 und sync_binlog = 1 bei MySQL). Ein Teil des Unterschieds hat einen konkreten Grund: MySQL 8.4 schreibt standardmäßig zusätzlich ein Binärlog (log_bin = 1), das für Replikation und Wiederherstellung zu einem Zeitpunkt gebraucht wird, und sichert auch das bei jeder Transaktion ab. PostgreSQL hat mit dem WAL nur ein Protokoll. Das ist kein Fehler von MySQL, sondern eine andere Voreinstellung. Wer bei MySQL das Binärlog abschaltet, wird schneller, verliert aber Point-in-Time-Recovery.

Ergebnis 5: Arbeitsspeicher

Der Unterschied direkt nach dem Start kommt vor allem daher, dass MySQL seinen InnoDB Buffer Pool (Standard: 128 MB) und diverse interne Strukturen sofort anlegt, während PostgreSQL Speicher erst bei Bedarf belegt. Auf einem Server mit 1 oder 2 GB RAM, auf dem neben der Datenbank noch Webserver, PHP und vielleicht ein Docker-Container laufen, ist das ein echtes Argument für PostgreSQL. Wie man den tatsächlichen Speicherbedarf eines Servers richtig misst (und warum die Zahlen in top oft lügen), haben wir in Wie viel RAM braucht ein Server? ausführlich aufgeschrieben.

Wichtig: Diese Zahlen sind kein Effizienzurteil unter Last. Eine produktive Datenbank soll viel RAM belegen, weil Daten im Speicher um Größenordnungen schneller sind als auf der Platte. Bei beiden stellst du das über einen einzigen Wert ein: shared_buffers bei PostgreSQL, innodb_buffer_pool_size bei MySQL.

Der größte praktische Unterschied: Wie streng sind sie mit deinen Daten?

Der Ruf von MySQL stammt aus einer Zeit, in der es kaputte Daten stillschweigend „repariert“ hat: Ein zu großer Wert wurde abgeschnitten, ein 30. Februar wurde zu 0000-00-00. Das stimmt bei MySQL 8.x mit Standardeinstellungen nicht mehr. Wir haben es getestet: Der Versuch, 300 in eine TINYINT-Spalte zu schreiben, endete in MySQL 8.4 mit ERROR 1264: Out of range value, und PostgreSQL lehnte den 30. Februar 2026 ab. Beide sind im Standard streng. Der sql_mode von MySQL 8.4 enthält ab Werk STRICT_TRANS_TABLES, NO_ZERO_DATE und ONLY_FULL_GROUP_BY.

Aber: Viele ältere Anwendungen und manche Hoster schalten diesen strikten Modus ab, weil alte Software sonst nicht läuft. Bei PostgreSQL gibt es keinen solchen Schalter. Die Strenge ist dort nicht verhandelbar.

Es gibt zwei Unterschiede, die auch 2026 noch regelmäßig Ärger machen, und beide haben wir nachgestellt:

Falle 1: Groß- und Kleinschreibung

In MySQL 8.4 ist die Standard-Sortierung utf8mb4_0900_ai_ci. Das ci steht für case insensitive, das ai für accent insensitive. Folge:

-- MySQL 8.4, Standard
SELECT 'abc' = 'ABC';                                     -- 1 (wahr)
SELECT 'Straße' = 'strasse' COLLATE utf8mb4_0900_ai_ci;   -- 1 (wahr)

In PostgreSQL ist 'abc' = 'ABC' falsch. Für Vergleiche ohne Groß-/Kleinschreibung gibt es ILIKE, lower() oder den Datentyp citext.

Das klingt nach Kleinkram, hat aber direkte Folgen. Wir haben eine Tabelle mit einer UNIQUE-Spalte für E-Mail-Adressen angelegt und zweimal dieselbe Adresse eingetragen, einmal als Max@Example.com, einmal als max@example.com:

• MySQL: ERROR 1062: Duplicate entry 'max@example.com'. Die zweite Adresse wird abgelehnt.
• PostgreSQL: beide Zeilen werden angenommen, die Tabelle enthält danach 2 Einträge.

Welches Verhalten „richtig“ ist, hängt vom Fall ab. Bei E-Mail-Adressen will man meistens das MySQL-Verhalten, in PostgreSQL muss man es explizit bauen (citext oder ein Unique-Index auf lower(email)). Bei Produktnummern oder Passwort-Tokens will man eher das PostgreSQL-Verhalten. Gefährlich wird es beim Umzug zwischen den Systemen: Eine Anwendung, die jahrelang auf MySQL lief, verlässt sich oft unbemerkt darauf, dass WHERE email = 'MAX@example.com' auch max@example.com findet. Nach einem Wechsel zu PostgreSQL findet die Login-Seite plötzlich Benutzer nicht mehr.

Falle 2: Tabellenänderungen in Transaktionen

Der Unterschied, den wir im Alltag am meisten schätzen:

BEGIN;
CREATE TABLE t_ddl (a int);
ROLLBACK;

• PostgreSQL: Nach dem ROLLBACK existiert die Tabelle nicht. Die Änderung ist rückgängig gemacht.
• MySQL: Die Tabelle existiert trotzdem. CREATE TABLE (wie jede Strukturänderung) beendet in MySQL die laufende Transaktion sofort mit einem stillen Commit. Das ROLLBACK danach hat nichts mehr zum Zurückrollen.

Warum das wichtig ist: Datenbank-Migrationen. Wenn ein Update deiner Anwendung zehn Tabellen ändert und Schritt sieben schiefgeht, rollt PostgreSQL alles zurück und deine Datenbank ist im alten, funktionierenden Zustand. Bei MySQL bleiben die Schritte eins bis sechs stehen, und du musst von Hand aufräumen, oft unter Zeitdruck, während die Seite nicht läuft. Wir haben beides erlebt, und die PostgreSQL-Variante ist die, bei der man ruhiger schläft.

Architektur: Prozesse gegen Threads

PostgreSQL startet für jede Verbindung einen eigenen Betriebssystem-Prozess. Das ist robust (stürzt eine Verbindung ab, reißt sie die anderen nicht mit) und einfach zu beobachten (du siehst jede Verbindung in ps), kostet aber pro Verbindung einige Megabyte und etwas Startzeit. Deshalb ist die Standardgrenze bei PostgreSQL 100 Verbindungen, und deshalb setzt man bei vielen gleichzeitigen Verbindungen einen Connection Pooler wie PgBouncer davor. Serverless-Plattformen und PHP-Anwendungen mit vielen Workern kommen ohne Pooler schnell an diese Grenze.

MySQL nutzt einen Thread pro Verbindung innerhalb eines einzigen Prozesses. Neue Verbindungen sind billiger, die Standardgrenze liegt bei 151, und klassische PHP-Anwendungen, die für jeden Seitenaufruf eine Verbindung öffnen und schließen, fühlen sich damit wohler. Das ist einer der Gründe, warum der klassische LAMP-Stack (Linux, Apache, MySQL, PHP) so gut mit MySQL zusammenspielt.

MVCC und VACUUM

Beide Datenbanken erlauben, dass gleichzeitig gelesen und geschrieben wird, ohne dass Leser auf Schreiber warten (Multi-Version Concurrency Control). Sie lösen es aber unterschiedlich:

• PostgreSQL schreibt bei einem UPDATE eine neue Version der Zeile in die Tabelle und markiert die alte als veraltet. Die alten Versionen räumt später ein Hintergrundprozess weg, das Autovacuum. Das funktioniert seit vielen Versionen gut von allein. Bei Tabellen mit extrem vielen Updates muss man es aber im Blick behalten, sonst wächst die Tabelle („Bloat“). Das erklärt auch die größere Tabelle in unserem Import-Test.
• MySQL (InnoDB) ändert die Zeile direkt an Ort und Stelle und legt die alte Version in einem separaten Undo-Log ab. Dadurch bleibt die Tabelle kompakter, dafür können sehr lange laufende Transaktionen das Undo-Log anwachsen lassen.

Für Einsteiger heißt das: Bei PostgreSQL solltest du wissen, dass es VACUUM gibt und dass es laufen muss. Bei MySQL solltest du wissen, dass der Buffer Pool die wichtigste Einstellung ist. Mehr Wartung braucht keine der beiden für ein normales Projekt.

Isolation: Was sieht eine Transaktion?

PostgreSQL arbeitet standardmäßig mit Read Committed: Jede Abfrage in einer Transaktion sieht alles, was andere bis zu diesem Moment bestätigt haben. MySQL nutzt standardmäßig Repeatable Read: Eine Transaktion sieht durchgehend den Stand von ihrem Anfang. Beide Verhalten sind legitim, aber Code, der auf das eine geschrieben wurde, kann sich beim anderen in seltenen Fällen anders verhalten, etwa bei Lagerbeständen, die zwei Kunden gleichzeitig kaufen. Wer so etwas baut, sollte in beiden Datenbanken mit SELECT … FOR UPDATE sperren, statt sich auf die Standard-Isolation zu verlassen.

Funktionen: Wo PostgreSQL deutlich mehr kann

Bei den reinen SQL-Grundlagen liegen beide nah beieinander. Darüber hinaus hat PostgreSQL einen großen Vorsprung, vor allem durch sein Erweiterungssystem. Eine Erweiterung installierst du mit einem einzigen Befehl (CREATE EXTENSION), und sie fügt der Datenbank neue Datentypen, Funktionen oder Indexarten hinzu:

• PostGIS: Geodaten, Entfernungen, Umkreissuchen. Der Standard für alles, was mit Karten zu tun hat.
• pgvector: Vektorsuche für KI-Anwendungen, etwa für „finde ähnliche Dokumente“ oder RAG-Systeme. Wenn du mit lokaler KI und eigenen Dokumenten arbeitest, ist PostgreSQL mit pgvector eine der einfachsten Lösungen, weil du keine zweite Datenbank brauchst. MySQL hat seit Version 9.0 zwar einen Datentyp VECTOR, das Ökosystem rund um pgvector ist aber deutlich weiter.
• TimescaleDB: Zeitreihen, etwa Messwerte oder Logs.
• pg_trgm: unscharfe Textsuche („Tippfehler-tolerant“).

Dazu kommen Funktionen, die direkt eingebaut sind: RETURNING (ein INSERT … RETURNING id liefert die neue ID ohne zweite Abfrage), Arrays als Spaltentyp, eigene Datentypen, partielle Indizes (CREATE INDEX … WHERE aktiv = true), Ausschluss-Constraints (zum Beispiel „keine zwei Buchungen für denselben Raum im selben Zeitraum“) und eine sehr gute Volltextsuche.

JSON in beiden Datenbanken

Beide speichern JSON, beide können es abfragen. PostgreSQL hat mit jsonb einen binären JSON-Typ, der sich komplett über einen GIN-Index durchsuchbar machen lässt. Abfragen wie „alle Produkte, deren Attribute {"farbe": "rot"} enthalten“ sind damit schnell, ohne dass du vorher festlegen musst, welche Felder du durchsuchen willst. MySQL kann JSON-Felder über funktionale Indizes und Multi-Value-Indizes beschleunigen, du musst dafür aber vorher sagen, welcher Pfad indiziert werden soll. Wer nicht genau weiß, was JSON überhaupt ist, findet die Grundlagen in unserem Artikel Was ist eine JSON-Datei?.

Wo MySQL die Nase vorn hat

Fairerweise gibt es auch Bereiche, in denen MySQL Vorteile hat:

• Verbreitung beim Hosting: Praktisch jedes Shared-Hosting-Paket in Deutschland bietet MySQL oder MariaDB, PostgreSQL ist dort deutlich seltener. Wer keinen eigenen Server betreiben will, hat mit MySQL mehr Auswahl.
• Software-Kompatibilität: WordPress unterstützt offiziell nur MySQL und MariaDB. Shopware 6 genauso. Magento genauso. Wer eines dieser Systeme betreibt, stellt sich die Frage PostgreSQL vs MySQL gar nicht.
• Replikation für Einsteiger: Eine einfache Primär-Replik-Kopie ist bei MySQL mit Bordmitteln schnell eingerichtet, und mit InnoDB Cluster und Group Replication gibt es eine eingebaute Hochverfügbarkeitslösung. PostgreSQL hat sehr gute Streaming- und logische Replikation, für automatisches Umschalten im Fehlerfall braucht man aber zusätzliche Werkzeuge wie Patroni.
• Speicherplatz: In unserem Test belegte MySQL rund 30 Prozent weniger Platz für dieselben Daten.
• Verbindungs-Overhead: Viele kurze Verbindungen verträgt MySQL ohne Pooler besser.

Kleine SQL-Unterschiede, die beim Wechsel auffallen

Wenn du von einer Datenbank zur anderen wechselst, stolperst du fast immer über dieselben Punkte:

Die meisten Frameworks (Laravel, Django, Rails, Prisma, Doctrine) verstecken diese Unterschiede hinter ihrer eigenen Abfragesprache. Solange du nur über das Framework arbeitest, ist ein Wechsel deshalb oft einfacher als gedacht. Handgeschriebenes SQL und gespeicherte Prozeduren musst du dagegen anpassen.

Ben Dicken erklärt die Architekturunterschiede (englisch, Mai 2026), vor allem Speicheraufbau und MVCC. Gut als Vertiefung zu den Abschnitten oben.

Was wir selbst einsetzen (und warum)

Wir betreiben beide Datenbanken produktiv, und die Aufteilung ist nicht ideologisch, sondern folgt der Software:

• PostgreSQL läuft bei uns für eigene Anwendungen: unser E-Commerce-Framework ForkCart (als postgres:16-alpine-Container, wie im Docker-Compose-Beispiel beschrieben) und mehrere interne Werkzeuge. Für neue Projekte ist es unsere Standardwahl.
• MySQL bzw. MariaDB läuft dort, wo die Software es vorgibt: bei Shopware- und WooCommerce-Installationen. Bei der Shopware-Installation stellt sich die Frage gar nicht.
• SQLite nutzen wir für kleine Dienste mit einem Schreiber (zum Beispiel unser eigenes Analytics-Werkzeug). Das ist oft die unterschätzte dritte Option: keine eigene Server-Software, eine einzige Datei.

Der Alltag fühlt sich bei beiden unaufgeregt an. Die Momente, in denen wir PostgreSQL bewusst vermissen, wenn wir in MySQL arbeiten, sind fast immer dieselben: Migrationen, die halb durchlaufen, und Auswertungen, die zu lange dauern.

PostgreSQL vs MySQL: Für wen sich welche Datenbank lohnt

Nimm PostgreSQL, wenn …

• du ein neues Projekt startest und frei wählen kannst,
• deine Anwendung Berichte, Statistiken, Filter oder Suche über größere Datenmengen braucht,
• du Geodaten, Vektorsuche (KI), Zeitreihen oder komplexe JSON-Daten speichern willst,
• dir Datenintegrität und sichere Migrationen wichtiger sind als minimaler Speicherplatz,
• du mit Django, Rails, Supabase, Prisma oder einem modernen Node.js-Stack arbeitest,
• dein Server wenig RAM hat und die Datenbank sich die Maschine mit anderen Diensten teilt.

Nimm MySQL (oder MariaDB), wenn …

• deine Software es verlangt: WordPress, WooCommerce, Shopware, Magento, viele PHP-Anwendungen,
• du auf Shared Hosting ohne eigenen Server angewiesen bist,
• dein Team MySQL gut kennt und keinen Grund zum Wechseln hat,
• du eine eingebaute Hochverfügbarkeitslösung ohne Zusatzwerkzeuge möchtest,
• du sehr viele kurzlebige Verbindungen ohne Connection Pooler hast.

Und wenn du dir unsicher bist: Ein Wechsel ist möglich, aber aufwendig. Werkzeuge wie pgloader übertragen eine komplette MySQL-Datenbank in einem Befehl nach PostgreSQL, inklusive Datentypen und Indizes. Die Arbeit steckt danach in den Anwendungsstellen, die sich auf MySQL-Verhalten verlassen (siehe die beiden Fallen oben). Plane dafür einen Testlauf mit einer Kopie der echten Daten ein, nicht nur mit Testdaten.

Checkliste: PostgreSQL oder MySQL in fünf Fragen

1. Schreibt deine Software eine Datenbank vor? Dann nimm die. Fertig.
2. Brauchst du Auswertungen über viele Daten, Geodaten oder Vektorsuche? Dann PostgreSQL.
3. Hast du nur Shared Hosting? Dann vermutlich MySQL/MariaDB, weil PostgreSQL dort selten angeboten wird.
4. Wie viel RAM hat der Server? Unter 2 GB mit mehreren Diensten: PostgreSQL ist sparsamer im Leerlauf.
5. Was kennt dein Team? Die Datenbank, die jemand nachts um drei im Notfall bedienen kann, ist mehr wert als zehn Prozent Geschwindigkeit.

Für einen eigenen Server zum Ausprobieren reicht ein kleiner VPS. Beide Datenbanken laufen dort als Docker-Container in unter einer Minute, genau wie in unserem Test.

Häufige Fragen zu PostgreSQL vs MySQL

Ist PostgreSQL schneller als MySQL?

Bei Auswertungen über viele Zeilen ja, in unserem Test drei- bis siebenmal (mit Parallelisierung), auch ohne Parallelisierung noch zwei- bis viermal. Bei einzelnen Datensätzen über einen Index sind beide etwa gleich schnell (rund 1 ms). Beim Schreiben einzelner Transaktionen war PostgreSQL in unserem Test etwa dreimal schneller, was zum Teil am standardmäßig aktiven Binärlog von MySQL liegt. Für eine normale Webseite ist keine der beiden der Flaschenhals.

Ist PostgreSQL schwerer zu lernen als MySQL?

Nein. Das SQL ist zu über 90 Prozent gleich. PostgreSQL ist bei Fehlern strenger, was am Anfang etwas mehr Fehlermeldungen bedeutet, aber auch weniger versteckte Probleme später. Die Kommandozeile psql hat eigene Kurzbefehle (\dt für Tabellen, \d tabelle für die Struktur), die man in einer Viertelstunde gelernt hat.

Sind MySQL und MariaDB dasselbe?

Nicht mehr ganz. MariaDB ist 2009 als Fork von MySQL entstanden und war lange ein direkter Ersatz. Inzwischen gibt es Unterschiede, etwa bei JSON, bei Systemvariablen und bei einigen SQL-Funktionen. Für WordPress, Shopware und die meisten PHP-Anwendungen sind beide austauschbar. Für den Vergleich mit PostgreSQL gelten die meisten Aussagen dieses Artikels für beide.

Welche Datenbank ist besser für Anfänger?

Wenn du mit WordPress oder einem PHP-Shopsystem einsteigst: MySQL, weil du sie sowieso brauchst. Wenn du Programmieren lernst und eine eigene Anwendung baust: PostgreSQL, weil es dich früh zu sauberen Daten erzieht und weil die meisten aktuellen Tutorials und Frameworks damit arbeiten.

Sind PostgreSQL und MySQL kostenlos?

Ja, beide. PostgreSQL steht unter einer freizügigen Lizenz ohne kommerzielle Edition. MySQL Community Edition steht unter der GPLv2 und ist kostenlos. Oracle verkauft zusätzlich die MySQL Enterprise Edition mit Support und Zusatzfunktionen. Für den normalen Betrieb einer Webanwendung brauchst du sie nicht.

Kann ich von MySQL zu PostgreSQL wechseln?

Ja. Die Daten selbst überträgt pgloader in den meisten Fällen automatisch. Aufwand entsteht in der Anwendung: handgeschriebenes SQL mit Backticks, AUTO_INCREMENT, ON DUPLICATE KEY UPDATE, und vor allem Code, der sich darauf verlässt, dass MySQL Groß-/Kleinschreibung beim Vergleich ignoriert. Teste mit einer Kopie der echten Daten.

Welche Datenbank braucht weniger Arbeitsspeicher?

Im Leerlauf PostgreSQL: 24 MB gegenüber 424 MB direkt nach dem Start in unserem Test. Unter Last bestimmen die Einstellungen (shared_buffers bzw. innodb_buffer_pool_size) den Verbrauch. Beide sollten in Produktion bewusst einen großen Teil des RAM bekommen, weil das die Abfragen schneller macht.

Welche Datenbank braucht weniger Speicherplatz?

MySQL. Unsere 2 Millionen Bestellungen belegten inklusive Index 120 MB in MySQL und 172 MB in PostgreSQL. Grund ist der Zeilenkopf von PostgreSQL, in dem Versionsinformationen für MVCC stehen.

Was ist besser für WordPress?

MySQL oder MariaDB. WordPress unterstützt offiziell keine andere Datenbank. Es gibt Plugins, die PostgreSQL oder SQLite anbinden, aber viele Plugins schreiben eigenes MySQL-SQL und funktionieren damit nicht zuverlässig.

Was ist besser für KI-Anwendungen?

PostgreSQL mit der Erweiterung pgvector. Damit speicherst du Texte, normale Daten und die Vektoren für die semantische Suche in einer einzigen Datenbank. Das spart dir eine separate Vektordatenbank und ist für kleine und mittlere Projekte meist völlig ausreichend.

Was nutzen große Firmen?

Beide. MySQL war das Rückgrat vieler großer Webplattformen der 2000er und 2010er Jahre, und viele davon laufen bis heute darauf. Neuere Plattformen und Cloud-Dienste setzen auffällig oft auf PostgreSQL oder auf PostgreSQL-kompatible Systeme. Für deine Entscheidung ist das aber weniger wichtig als die Frage, welche Software du betreiben willst.

Fazit

PostgreSQL vs MySQL ist 2026 keine Glaubensfrage mehr, sondern eine Frage des Einsatzzwecks. Die alten Vorurteile stimmen nicht mehr: MySQL schluckt im Standard keine kaputten Daten mehr, und PostgreSQL ist nicht kompliziert. In unserem eigenen Test auf einem kleinen 2-Kern-Server war PostgreSQL bei Auswertungen drei- bis siebenmal schneller, beim Import doppelt so schnell und im Leerlauf um 400 MB sparsamer. MySQL war bei einzelnen Abfragen unter Volllast nahezu gleichauf und brauchte rund 30 Prozent weniger Speicherplatz.

Unsere Empfehlung: Neue Projekte auf PostgreSQL. Bestehende Projekte und alles rund um WordPress, Shopware und Magento bleiben auf MySQL oder MariaDB. Und wer das noch nicht kennt: Sieh dir für kleine Dienste auch SQLite an. Der direkte Vergleich SQLite vs PostgreSQL steht bei uns als Nächstes auf der Liste.