MySQL und MariaDB: der klassische LAMP-Stack 2026 ehrlich bewertet

Was sind MySQL und MariaDB?

MySQL ist die klassische relationale Datenbank des LAMP-Stacks (Linux, Apache, MySQL, PHP), die seit 1995 unter GPL-2 entwickelt wird. Seit 2010 gehört das Projekt Oracle, was bei einigen Anwendern Bedenken zur langfristigen OSS-Ausrichtung weckt. MariaDB ist der Open-Source-Fork von MySQL, gestartet 2009 von Michael "Monty" Widenius (dem ursprünglichen MySQL-Erfinder) als Reaktion auf die Oracle-Übernahme. MariaDB Foundation steht hinter dem Projekt.

Im Mai 2026 ist MySQL 8.4 LTS aktuell (LTS bis April 2032), MariaDB 11.4 LTS ist die stabile Long-Term-Variante (Support bis Mai 2029). Beide Datenbanken sind weiterhin in den meisten Linux-Distros als Default-RDBMS verfügbar -- bei Debian und Ubuntu hat MariaDB seit Jahren die Default-Position eingenommen.

Funktional sind beide Systeme nahe verwandt, weichen aber bei JSON-Support, Window-Functions, CTEs, Storage-Engines und Sicherheit auseinander. MariaDB hat eine eigene Spatial-Erweiterung, ColumnStore (eine Columnar-Engine für Analytics), Galera Cluster für Multi-Master und Oracle-Compatibility-Mode. MySQL bietet dafür JSON-Path und JSON-Schema-Validation reifer, hat die stärkere Group Replication und InnoDB Cluster, und MySQL HeatWave als Cloud-Analytics-Lösung. Wer einen neuen Stack 2026 baut, sollte die spezifischen Unterschiede prüfen -- die Wahl ist nicht trivial.

Lizenzmodell: MySQL Community Edition bleibt GPL-2 mit klassischer Dual-License-Strategie von Oracle (Enterprise Edition kostenpflichtig). MariaDB ist GPL-2 für den Server-Kern und nutzt die Business Source License (BSL) für einige Enterprise-Module mit 4-Jahre-Konversion auf GPL-2. Für reine KMU-Selbstnutzung beider Server gibt es keine Lizenz-Probleme.

Warum es wichtig ist

MySQL und MariaDB sind in Hunderttausenden produktiven CH-KMU-Systemen im Einsatz: PHP-Shops, Wordpress-Sites, eingebettete CMS, Anwendungen aus der Bull-Markt-Phase 2010-2018. Wer eine bestehende Applikation hat, hat eine reale Frage -- bleiben oder migrieren.

Drei Argumente sprechen für bleiben. Erstens: Stabilität. Eine laufende MySQL-Anwendung mit 5-10 Jahren produktiver Geschichte hat ihr Worst-Case-Verhalten bereits gezeigt. Datenkorruption durch Bugs ist extrem selten, Backup-Routinen sind eingespielt. Zweitens: Tooling-Reife. phpMyAdmin, MySQL Workbench, Percona Toolkit und Monitoring-Lösungen sind über 20 Jahre gereift -- die Operations-Erfahrungskurve ist flach. Drittens: Hosting-Verfügbarkeit. Jeder Shared-Hoster bietet MySQL/MariaDB an, jeder Cloud-Provider hat Managed-Services (RDS, Cloud SQL, Azure Database for MySQL).

Drei Argumente sprechen für Migration auf Postgres. Erstens: Funktions-Tiefe. JSON, Window-Functions, CTEs, pgvector, PostGIS sind in Postgres reifer. Wer ein 2026er-Greenfield-Projekt startet, bekommt mehr für das gleiche Geld. Zweitens: Lizenz-Klarheit. Postgres-License (MIT-ähnlich) ist permissiver als GPL-2 / BSL. Drittens: Migrationspfad zu modernen Systemen (Cockroach, Supabase, Neon) ist mit Postgres einfacher.

Für den CH-Treuhand-Markt empfehlen wir 2026 folgende Heuristik: bestehende MySQL/MariaDB-Anwendungen bleiben auf MySQL/MariaDB, ggf. mit MariaDB-Migration (Drop-in-Replacement) statt Oracle-MySQL. Neue Anwendungen mit OLTP-Schwerpunkt starten auf PostgreSQL. Hybride sind möglich -- eine Hauptdatenbank pro Anwendung, kein DB-Zoo. Datenresidenz erfüllt beide Systeme auf Hetzner Falkenstein.

Wie es funktioniert

MySQL und MariaDB sind klassische Multi-Process-Server mit Threaded-Connection-Handling. Der mysqld-Prozess akzeptiert Verbindungen, jede Verbindung bekommt einen Worker-Thread. Speicher-Engine InnoDB ist seit MySQL 5.5 (2010) Default und liefert ACID-Transaktionen, Foreign Keys und Row-Level-Locking. Ältere MyISAM-Tabellen sollten 2026 keinen produktiven Einsatz mehr haben.

Ein minimal-produktiver Setup sieht so aus:

CREATE DATABASE treuhand CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; USE treuhand;

CREATE TABLE mandanten ( id BIGINT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(255) NOT NULL, metadata JSON, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_name (name), INDEX idx_metadata ((CAST(metadata->>"$.branche" AS CHAR(100)))) );

Der Charset utf8mb4 ist Pflicht für korrekte Emoji- und Unicode-Behandlung -- das alte "utf8" ist nicht echt UTF-8 und hat in Legacy-Systemen viele Probleme verursacht. Beim Einrichten neuer Schemen 2026: utf8mb4 als Default, utf8mb4_0900_ai_ci (MySQL) oder utf8mb4_uca1400_ai_ci (MariaDB) als Collation.

Replikation läuft über den Binary-Log: Primary schreibt jede Schreib-Operation in binlog, Replica liest und repliziert. Asynchron, semi-synchron oder synchron (GTID-basiert). Galera Cluster (MariaDB) und Group Replication (MySQL) bieten Multi-Master-Setups -- mit erhöhter Komplexität und einigen Einschränkungen für DDL und Locks.

Backup-Standard: nightly mysqldump für kleine Datenbanken (< 20 GB), mariabackup / xtrabackup für grossere (Online-Backup ohne Lock). Plus Binary-Log-Archiving für PITR. Recovery: mysqldump zurückspielen, dann Binary-Logs bis zum gewünschten Zeitpunkt anwenden. Eine 50-GB-Datenbank ist in 30-60 Minuten zurück -- langsamer als Postgres pg_basebackup, aber bewährt.

Monitoring über mysqld_exporter für Prometheus, Percona Monitoring Plugins für Zabbix/Grafana. Schlüssel-Metriken: InnoDB Buffer Pool Hit Ratio (> 95 Prozent angestrebt), Threads_running, Slow-Query-Log, Replication Lag.

MySQL/MariaDB in 5 Schritten produktiv

1. 01Hetzner-Server bereitstellen, MariaDB 11 (oder MySQL 8.4) als Docker-Container starten, my.cnf mit innodb_buffer_pool_size auf ca. 60 Prozent des RAM tunen.
2. 02Schema mit utf8mb4 und InnoDB als Default anlegen, Foreign Keys und Indexes konsequent setzen, MyISAM-Tabellen verbieten.
3. 03Backup-Strategie: nightly mariabackup auf separate Storage Box, kontinuierliches Binary-Log-Archiving, Retention 30 Tage täglich.
4. 04Monitoring anbinden: mysqld_exporter für Prometheus, Slow-Query-Log mit long_query_time=1, Grafana-Dashboard mit Buffer-Pool-Hit-Ratio und Threads_running.
5. 05Disaster-Recovery-Test quartalsweise: Backup auf separatem Server zurückspielen, PITR mit Binary-Logs auf einen Zeitpunkt vor 1 Stunde, Runbook aktualisieren.

Wann MySQL oder MariaDB einsetzen

Die richtige Wahl, wenn (a) ein bestehendes System auf MySQL/MariaDB stabil läuft, (b) eine PHP-basierte Anwendung mit MySQL-Hosting deployed werden soll, oder (c) das Team langjährige MySQL-Erfahrung mitbringt und keine Postgres-spezifischen Features braucht.

Konkrete Szenarien: WordPress-Sites mit hohem Traffic, klassische LAMP-Anwendungen, Magento- oder PrestaShop-Shops, alte Symfony/Laravel-Anwendungen mit etablierter MySQL-Anbindung, Shared-Hosting-Setups in der Schweiz, in denen MySQL die einzige verfügbare DB ist.

MariaDB als Drop-in-Replacement für Oracle-MySQL ist 2026 attraktiv: Wechsel ohne Anwendungscode-Änderungen, Default in Debian/Ubuntu, langfristig OSS-orientiert, Galera Cluster verfügbar. Wer bei MySQL bleibt, sollte die Oracle-Lizenz-Themen und das Enterprise-vs-Community-Modell verstehen -- es gibt keine Royalty-Pflicht für Community Edition unter GPL-2, aber Oracle kontrolliert die Roadmap.

Wann NICHT

Für ein Greenfield-Projekt im Mai 2026 ist PostgreSQL die bessere Default-Wahl -- stärkere JSON-Funktionen, native Vector-Search via pgvector, breiteres Extensions-Ecosystem, sauberere Lizenz. MySQL/MariaDB sind kein Fehler, aber sie sind 2026 nicht mehr die offensichtlich beste Wahl, die sie noch 2015 waren.

Für hochkomplexe Analytics-Queries mit Window-Functions, Recursive CTEs und JSON-Aggregationen ist MySQL schwächer als Postgres -- Reports werden komplizierter zu schreiben. Wer Reporting-Heavy-Workloads hat, plant entweder Postgres oder eine columnar-DB wie ClickHouse / DuckDB daneben.

Für KI-RAG-Pipelines mit Vector-Search ist MySQL/MariaDB ohne native Vector-Extension nicht geeignet -- man braucht eine zusätzliche Vektor-DB (Qdrant, Weaviate, Pinecone). Postgres mit pgvector erspart diesen zweiten Server.

Für Multi-Region-Synchronizität mit globaler Konsistenz ist MySQL Group Replication möglich, aber operativ aufwendig. CockroachDB ist die bessere Wahl, wenn echte Multi-Region-Anforderungen bestehen.

Für SaaS-Produkte, die später potenziell auf Cloud-Hyperscaler-Database-Dienste wechseln möchten (Aurora, Cloud SQL), ist Postgres-Kompatibilität ein grösserer Vorteil als MySQL-Kompatibilität -- die ganze CockroachDB- und Supabase-Welt baut auf Postgres-Wire-Protokoll, nicht auf MySQL.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. MySQL 8.4 LTS Release Notes · 2026-05
2. MariaDB 11.4 LTS Release Notes · 2026-05
3. MariaDB Licensing FAQ (BSL, GPL-2) · 2026-04
4. MySQL vs MariaDB feature comparison · 2026-04