DevOps 12 Min Lesezeit

Die Wahl der richtigen Datenbank ist eine der fundamentalen Infrastruktur-Entscheidungen, die ein Entwickler oder DevOps-Ingenieur treffen muss. PostgreSQL und MySQL dominieren seit Jahrzehnten den Markt der relationalen Open-Source-Datenbanken, doch die Frage PostgreSQL vs. MySQL ist 2026 aktueller denn je. Mit MySQL 9.0 und PostgreSQL 17 haben beide Systeme bedeutende Sprünge nach vorne gemacht – sowohl in puncto Performance als auch bei den Features.

Dieser Vergleich beleuchtet alle relevanten Aspekte für das Datenbank-Hosting im Jahr 2026: von der grundlegenden Philosophie beider Systeme über SQL-Compliance, Hochverfügbarkeit und Monitoring bis hin zu konkreten Hosting-Empfehlungen für VPS-Umgebungen. Egal ob du eine WordPress-Seite betreibst, eine Analytics-Plattform aufbaust oder eine Microservices-Architektur mit mehreren Datenbankinstanzen planst – hier erfährst du, welches System für deinen Anwendungsfall die richtige Wahl ist.

Wer tiefer in die Materie einsteigen möchte, findet bei Amazon eine gute Auswahl an Datenbank-Literatur für beide Systeme*.

Geschichte & Philosophie: Zwei Welten, ein Ziel

Die Ursprünge beider Datenbanken könnten unterschiedlicher kaum sein. PostgreSQL wurde 1996 an der University of California, Berkeley, als Nachfolger des Ingres-Projekts gestartet. Von Anfang an lag der Fokus auf Standardkonformität und Erweiterbarkeit. PostgreSQL versteht sich als das Oracle der Open-Source-Welt – eine Datenbank, die möglichst viele SQL-Standards implementiert und sich durch benutzerdefinierte Typen, Operatoren und Funktionen nahezu unbegrenzt erweitern lässt.

MySQL hingegen entstand 1995 aus dem Bedürfnis nach einer schnellen, einfachen und zuverlässigen Datenbank für Webanwendungen. Die Philosophie von MySQL war schon immer: "Es muss funktionieren und schnell sein." Diese Fokussierung auf Einfachheit und Geschwindigkeit hat MySQL zur unangefochtenen Nummer eins im LAMP-Stack (Linux, Apache, MySQL, PHP/Python/Perl) gemacht – und bis heute läuft ein Großteil des Internets auf MySQL-basierten Systemen.

Während PostgreSQL also den akademischen, standardgetriebenen Ansatz verfolgt, setzt MySQL auf pragmatische Schnelligkeit und einfache Administrierbarkeit. Diese grundlegenden Unterschiede prägen bis heute die Stärken und Schwächen beider Systeme – und machen die Wahl letztlich von deinem konkreten Anwendungsfall abhängig.

2026 im Vergleich: MySQL 9.0 vs. PostgreSQL 17

Beide Datenbanken haben in den letzten Jahren enorme Fortschritte gemacht. Werfen wir einen Blick auf die aktuellen Hauptversionen und ihre wichtigsten Neuerungen.

MySQL 9.0 – Der Innovationsschub

Mit MySQL 9.0 hat Oracle die Datenbank grundlegend modernisiert. Die wichtigsten Neuerungen sind ein deutlich verbesserter JSON-Datentyp mit Multi-Value-Indexes, native VECTOR-Unterstützung für KI/ML-Anwendungen und eine optimierte InnoDB-Engine mit besserer Nutzung moderner NVMe-SSDs. Die Performance bei OLTP-Workloads (Online Transaction Processing) wurde um bis zu 30 Prozent gegenüber MySQL 8.0 gesteigert. Besonders hervorzuheben ist die verbesserte Integration mit MySQL HeatWave – der In-Memory-Analytics-Engine, die MySQL nun auch für Data-Workloads attraktiv macht.

PostgreSQL 17 – Der stabile Riese

PostgreSQL 17 setzt den bewährten Kurs fort: mehr SQL-Compliance, bessere Performance und erweiterte Funktionalität. Zu den Highlights gehören die vollständige Implementierung des SQL/JSON-Standards (SQL:2023), signifikante Verbesserungen beim MERGE-Befehl, eine optimierte WAL-Architektur für schnellere Replikation und massive Performance-Steigerungen bei WINDOW-Funktionen und CTEs (Common Table Expressions). Der neue pg_createsubscriber-Befehl vereinfacht zudem die Einrichtung logischer Replikation erheblich.

Benchmark-Vergleich

In standardisierten Benchmarks zeigt sich ein differenziertes Bild:

💡 Praxis-Tipp: Entscheidend ist nicht der reine Benchmark, sondern dein Workload-Profil. Für eine WordPress-Seite mit 90% Lesezugriffen ist MySQL oft die bessere Wahl. Für eine Analytics-Plattform mit komplexen Aggregationen ist PostgreSQL die klar bessere Option. Vertiefende SQL-Literatur findest du bei Amazon*.

SQL-Standard-Compliance: PostgreSQL führt, MySQL holt auf

Ein zentrales Unterscheidungsmerkmal war und ist die SQL-Compliance. PostgreSQL implementiert den SQL-Standard deutlich umfassender als MySQL – und dieser Vorsprung ist auch 2026 noch spürbar.

WINDOW-Funktionen und CTEs

PostgreSQL bietet seit Version 9.1 vollständige Unterstützung für WINDOW-Funktionen mit RANGE, ROWS und GROUPS-Frames, inklusive aller Standard-Aggregatfunktionen. MySQL hat zwar in Version 8.0 ebenfalls WINDOW-Funktionen eingeführt, hinkt jedoch bei der Frame-Unterstützung und Performance hinterher:

-- PostgreSQL: Volle WINDOW-Unterstützung
SELECT
  department,
  employee_name,
  salary,
  AVG(salary) OVER (
    PARTITION BY department
    ORDER BY salary
    ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
  ) AS running_avg
FROM employees;

-- MySQL 9.0: Gleiche Syntax, aber langsamer bei großen Datensätzen
SELECT
  department,
  employee_name,
  salary,
  AVG(salary) OVER (
    PARTITION BY department
    ORDER BY salary
    ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
  ) AS running_avg
FROM employees;

JSON-Support im Detail

Beide Datenbanken bieten mittlerweile exzellenten JSON-Support, aber mit unterschiedlichen Schwerpunkten:

PostgreSQL hat hier die Nase vorn, weil jsonb eine echte Binärstruktur ist, während MySQL JSON als validierten String speichert. Für Anwendungen, die JSON intensiv nutzen (z. B. document-store-artige Patterns), ist PostgreSQL daher die bessere Wahl.

Array-Typen und benutzerdefinierte Typen

Ein Alleinstellungsmerkmal von PostgreSQL sind native Array-Typen. MySQL hat kein Äquivalent – du musst auf JSON oder separate Join-Tabellen ausweichen:

-- PostgreSQL: Native Arrays
CREATE TABLE articles (
  id SERIAL PRIMARY KEY,
  title TEXT,
  tags TEXT[],
  ratings INTEGER[]
);

INSERT INTO articles (title, tags, ratings)
VALUES ('PostgreSQL vs MySQL', ARRAY['datenbank', 'vergleich', 'devops'], ARRAY[5,4,5]);

SELECT * FROM articles WHERE 'devops' = ANY(tags);

-- MySQL: Kein Array-Typ – Workaround mit JSON
CREATE TABLE articles (
  id INT AUTO_INCREMENT PRIMARY KEY,
  title TEXT,
  tags JSON,
  ratings JSON
);

SELECT * FROM articles WHERE JSON_CONTAINS(tags, '"devops"');

Hosting auf dem VPS: RAM, IOPS und Konfiguration

Beide Datenbanken lassen sich auf einem VPS hosten, stellen jedoch unterschiedliche Anforderungen an die Hardware. Die Wahl des richtigen VPS ist entscheidend für die Performance deiner Datenbank.

Ressourcenanforderungen im Vergleich

PostgreSQL ist dafür bekannt, mehr Wert auf korrekte Ergebnisse als auf minimale Ressourcennutzung zu legen. Der PostgreSQL-Prozess pro Verbindung (Fork-Modell) benötigt mehr RAM als MySQLs Thread-Modell. MySQL 9.0 mit InnoDB kommt mit weniger Speicher aus, profitiert aber ebenfalls von viel RAM für den Buffer Pool:

PostgreSQL-Konfiguration für den VPS

# postgresql.conf – Optimierte Einstellungen für 4 GB VPS
shared_buffers = 1GB                # 25% des RAM
effective_cache_size = 3GB          # 75% des RAM
work_mem = 64MB                     # Pro Sortierung/Join
maintenance_work_mem = 256MB        # Für VACUUM, INDEX
random_page_cost = 1.1              # NVMe-SSDs: niedriger Wert
effective_io_concurrency = 200      # Für SSDs
wal_buffers = 64MB
max_worker_processes = 4
max_parallel_workers_per_gather = 2

MySQL-Konfiguration für den VPS

# my.cnf – Optimierte Einstellungen für 4 GB VPS
innodb_buffer_pool_size = 2G        # 50% des RAM
innodb_log_file_size = 512M
innodb_flush_log_at_trx_commit = 2  # Höhere Performance (leichter Datenverlust bei Crash)
innodb_flush_method = O_DIRECT
innodb_io_capacity = 2000           # Für NVMe-SSDs
innodb_read_io_threads = 8
innodb_write_io_threads = 8
query_cache_type = 0                # Deaktiviert (veraltet)
max_connections = 100
table_open_cache = 2000

Wer einen spezialisierten Datenbank-Hosting-Dienst sucht, findet bei Anbietern wie Aiven, DigitalOcean Managed Databases oder Hetzner Cloud Datenbanken sowohl MySQL als auch PostgreSQL als Managed Service – mit automatischem Failover, Backups und integriertem Monitoring. Für selbstverwaltete Setups ist das passende Server-Equipment bei Amazon* ein guter Ausgangspunkt.

Hochverfügbarkeit: Streaming Replication, Galera Cluster & Patroni

In der Produktion ist Hochverfügbarkeit (HA) kein Luxus, sondern eine Notwendigkeit. Beide Datenbanken bieten etablierte Lösungen, unterscheiden sich aber in der Umsetzung.

PostgreSQL HA mit Patroni

Patroni ist der De-facto-Standard für PostgreSQL-Hochverfügbarkeit. Es nutzt Streaming Replication (synchron oder asynchron), DCS (Distributed Consensus Store wie etcd oder Consul) für das Leader-Election und automatisches Failover:

# Patroni-Konfiguration (Auszug)
scope: pg-cluster
namespace: /service/
name: pg-node1

restapi:
  listen: 0.0.0.0:8008
  connect_address: 10.0.0.1:8008

etcd:
  host: 10.0.0.10:2379

bootstrap:
  dcs:
    ttl: 30
    loop_wait: 10
    retry_timeout: 10
    maximum_lag_on_failover: 1048576
    postgresql:
      use_pg_rewind: true
      use_slots: true
      parameters:
        hot_standby: "on"
        wal_level: replica
        max_wal_senders: 5
        max_replication_slots: 5

postgresql:
  listen: 0.0.0.0:5432
  connect_address: 10.0.0.1:5432
  data_dir: /data/postgresql
  bin_dir: /usr/lib/postgresql/17/bin
  parameters:
    unix_socket_directories: /var/run/postgresql
  authentication:
    replication:
      username: replicator
      password: securepassword
    superuser:
      username: postgres
      password: securepassword

MySQL HA mit Galera Cluster und Group Replication

MySQL bietet zwei etablierte HA-Ansätze: Galera Cluster (über MariaDB oder Percona XtraDB Cluster) und die native MySQL Group Replication (Inline in MySQL 9.0):

# Galera-Cluster-Konfiguration (wsrep.cnf)
[mysqld]
wsrep_on = ON
wsrep_provider = /usr/lib/galera/libgalera_smm.so
wsrep_cluster_name = mysql-cluster
wsrep_cluster_address = gcomm://10.0.0.1,10.0.0.2,10.0.0.3
wsrep_node_name = mysql-node1
wsrep_node_address = 10.0.0.1
wsrep_sst_method = rsync
wsrep_slave_threads = 8
innodb_autoinc_lock_mode = 2

Während Patroni auf asynchrone/synchrone Streaming Replication setzt und bei Ausfall eines primären Knotens automatisch ein Standby-Promotion durchführt, arbeitet Galera Cluster mit synchroner Multi-Master-Replikation: Jeder Knoten kann Schreiboperationen akzeptieren. Das bietet geringere Failover-Zeiten, erfordert aber ein performantes Netzwerk (unter 1 ms Latenz zwischen den Knoten).

Monitoring: pg_stat_statements vs. Performance Schema

Ohne Monitoring bist du blind für Performance-Probleme. Beide Datenbanken bieten leistungsfähige Instrumentierung, unterscheiden sich aber in der Handhabung.

PostgreSQL: pg_stat_statements und pg_stat_activity

Die PostgreSQL-Erweiterung pg_stat_statements ist das wichtigste Werkzeug für Query-Analyse und Performance-Tuning:

-- pg_stat_statements aktivieren (in postgresql.conf)
shared_preload_libraries = 'pg_stat_statements'
pg_stat_statements.max = 10000
pg_stat_statements.track = all

-- Die langsamsten Abfragen ermitteln
SELECT
  queryid,
  LEFT(query, 80) AS query_short,
  calls,
  ROUND(total_exec_time::numeric, 2) AS total_time_ms,
  ROUND(mean_exec_time::numeric, 2) AS avg_time_ms,
  ROUND((100 * total_exec_time / SUM(total_exec_time) OVER ())::numeric, 2) AS percentage
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 10;

Ergänzend dazu bietet PostgreSQL mit pg_stat_activity Einblick in laufende Verbindungen und Sperren, pg_stat_bgwriter für Checkpointer-Performance und pg_stat_user_tables für sequenzielle Scans und Cache-Hit-Raten.

MySQL: Performance Schema und Slow Query Log

Das MySQL Performance Schema sammelt detaillierte Metriken auf Event-Basis – von Statements über Wait-Events bis zu Memory-Usage:

-- Performance Schema aktivieren (in my.cnf)
performance_schema = ON
performance_schema_consumer_events_statements_history_long = ON

-- Die langsamsten Abfragen identifizieren
SELECT
  DIGEST_TEXT,
  COUNT_STAR,
  ROUND(SUM_TIMER_WAIT / 1000000000, 2) AS total_time_ms,
  ROUND(AVG_TIMER_WAIT / 1000000000, 2) AS avg_time_ms,
  ROUND(SUM_ROWS_EXAMINED / COUNT_STAR) AS avg_rows_examined
FROM performance_schema.events_statements_summary_by_digest
ORDER BY SUM_TIMER_WAIT DESC
LIMIT 10;

-- Slow Query Log aktivieren
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow-query.log
long_query_time = 2    # Abfragen über 2 Sekunden loggen

Das MySQL Performance Schema ist extrem detailliert, aber auch ressourcenhungrig. Auf VPS mit weniger als 2 GB RAM solltest du die Sampling-Rate reduzieren. PostgreSQLs pg_stat_statements ist schlanker und daher besser für kleinere VPS-Umgebungen geeignet.

Migration zwischen PostgreSQL und MySQL

Der Wechsel zwischen beiden Systemen ist kein alltägliches Projekt, aber es gibt gute Gründe dafür: von MySQL zu PostgreSQL für mehr SQL-Compliance oder bessere Analytics-Features, oder von PostgreSQL zu MySQL für eine einfachere WordPress/ LAMP-Integration.

pgloader – Der Migrations-Klassiker

pgloader ist das bewährteste Tool für die Migration von MySQL nach PostgreSQL. Es konvertiert automatisch Datentypen, Indizes und sogar viele MySQL-spezifische Funktionen:

# pgloader – Migration von MySQL nach PostgreSQL
pgloader mysql://user:password@localhost/source_db \
         postgresql://user:password@localhost/target_db

# Mit detaillierter Konfigurationsdatei
LOAD DATABASE
  FROM mysql://user:password@localhost:3306/source_db
  INTO postgresql://user:password@localhost:5432/target_db

WITH include drop, create tables, create indexes, reset sequences,
     batch rows = 10000, batch concurrency = 4

CAST type datetime to timestamptz drop default drop not null using zero-dates-to-null,
     type date drop default drop not null using zero-dates-to-null;

AWS DMS – Managed Migration in der Cloud

AWS Database Migration Service (DMS) unterstützt sowohl homogene als auch heterogene Migrationen zwischen MySQL und PostgreSQL. Der Vorteil: DMS kann während der Migration Changes kontinuierlich replizieren (Change Data Capture), sodass die Downtime auf wenige Minuten reduziert wird. Ähnliche Dienste bieten Azure Database Migration Service und Google Cloud Database Migration Service.

Für kleinere Projekte mit überschaubaren Datenmengen (unter 50 GB) ist pgloader die einfachste und schnellste Lösung. Bei großen Datenbanken im Terabyte-Bereich solltest du auf Cloud-Migration-Dienste mit CDC setzen.

Kleine Projekte: SQLite als dritte Option

Nicht jedes Projekt braucht einen eigenen Datenbankserver. Für kleine Anwendungen, Embedded-Systeme, Entwicklungsumgebungen und Single-User-Szenarien ist SQLite oft die bessere Wahl – unabhängig von der Frage PostgreSQL vs. MySQL.

SQLite ist eine serverlose, dateibasierte Datenbank-Engine, die keine separate Installation, keinen laufenden Dienst und keine Netzwerkkonfiguration benötigt. Die Performance bei kleinen Datenmengen (bis zu einigen Hundert Megabyte) ist hervorragend – oft schneller als PostgreSQL oder MySQL, weil keine Interprozess-Kommunikation anfällt.

📌 Entscheidungsmatrix für dein nächstes Projekt:

  • Blog / kleine Webseite → SQLite (oder MySQL bei Shared Hosting)
  • WordPress / WooCommerce → MySQL / MariaDB
  • SaaS-Plattform mit vielen CRUD-Operationen → MySQL
  • Analytics / Data Warehouse → PostgreSQL
  • Geodaten / GIS-Anwendung → PostgreSQL + PostGIS
  • Microservices mit JSON-Dokumenten → PostgreSQL (jsonb)
  • Embedded / Mobile App → SQLite

Fazit & Empfehlung: PostgreSQL für Analytics, MySQL für LAMP

Nach allen technischen Vergleichen bleibt die Antwort auf die Frage PostgreSQL vs. MySQL 2026 differenziert – und hängt letztlich von deinem spezifischen Use Case ab.

PostgreSQL 17 ist die richtige Wahl, wenn:

MySQL 9.0 ist die richtige Wahl, wenn:

Für DevOps-Teams, die beide Systeme betreiben, empfiehlt sich eine Strategie der polyglotten Persistenz: Verwende PostgreSQL für Analytics, Reporting und datenintensive Microservices, während MySQL weiterhin gut für klassische Webanwendungen und Content-Management-Systeme geeignet ist. Die Fachliteratur zu beiden Systemen bei Amazon* kann dir bei der Vertiefung helfen.

Am Ende gibt es 2026 keine falsche Entscheidung – beide Datenbanken sind hervorragend, produktionserprobt und werden auch in den kommenden Jahren die Datenbank-Welt dominieren. Wichtig ist, dass du die Stärken deines gewählten Systems kennst und entsprechend nutzt.

📖 Ähnliche Artikel