MariaDB vs. PostgreSQL für Self-Hosted-KMU

Wer im Mittelstand eigene Anwendungen betreibt — Nextcloud fürs Team, GitLab für die Entwicklung, Mailcow für die Kommunikation, dazu vielleicht ein selbstgehostetes Ticketsystem — landet früher oder später bei der Frage: MariaDB oder PostgreSQL? Beide sind ausgereift, quelloffen und laufen ohne Lizenzkosten in einer LXC- oder VM-Instanz auf Ihrem Proxmox-Cluster. Der eigentliche Unterschied liegt nicht in synthetischen Benchmarks, sondern in Betriebsalltag, Feature-Set und der Frage, welche Anwendungen Sie tatsächlich einsetzen.

Dieser Artikel richtet sich an IT-Verantwortliche in KMU, die eine bewusste Entscheidung treffen möchten — statt “Wir hatten schon immer MySQL”. Wir schauen auf typische Self-Hosting-Stacks, die charakteristischen Stärken beider Datenbanken, Backup-Strategien und die häufigsten Stolperfallen bei einer Migration.

Wo MariaDB nach wie vor die richtige Wahl ist

MariaDB ist der von der Community weitergeführte MySQL-Fork und hat sich als De-facto-Standard im PHP-Ökosystem etabliert. Wenn Ihr Stack auf klassischen Web-Applikationen basiert, ist MariaDB oft die schmerzfreie Option: Nextcloud ist auf MariaDB/MySQL optimiert und dokumentiert die meisten Tuning-Empfehlungen dafür, WordPress-Multisite-Installationen, Kimai zur Zeiterfassung, ältere Ticketing-Systeme wie OTRS-Community-Edition oder Zammad in Standardkonfiguration — all das läuft mit MariaDB “wie erwartet”.

Praktische Vorteile aus unserer Sicht:

• Ressourcenverbrauch: Eine MariaDB-Instanz für eine 30-Mitarbeiter-Nextcloud fühlt sich in einem 2-vCPU/4-GB-LXC ausgesprochen wohl.
• Backup-Tooling: mariabackup liefert konsistente Hot-Backups ohne aufwendige Vorbereitung, mysqldump bleibt für kleine Datenbanken die pragmatische Lösung.
• Betriebsvertrautheit: Fast jeder Linux-Admin hat schon mysql -u root -p getippt. Für kleine Teams ohne dedizierten DBA senkt das die Einstiegshürde spürbar.
• Kompatibilität: Klassische PHP-Anwendungen erwarten MySQL-Dialekt. Prepared Statements, AUTO_INCREMENT, ENGINE=InnoDB — funktioniert direkt.

Als Version empfehlen wir aktuell MariaDB 11.4 LTS (Support bis Mai 2029). Die 10.11-LTS-Reihe läuft bei uns noch auf einigen Bestandssystemen, aber Neuinstallationen setzen wir auf 11.4 auf.

Wo PostgreSQL klar die Nase vorn hat

PostgreSQL ist die richtige Wahl, sobald Ihre Anwendung mehr will als “Daten in Tabellen schreiben”. GitLab läuft ausschließlich mit PostgreSQL — MySQL-Support wurde bereits 2019 entfernt. Moderne DMS- und ERP-Lösungen wie Odoo, Metabase für BI-Dashboards, Discourse als Community-Forum, viele Python/Django-Anwendungen und praktisch alles im GIS-Umfeld setzen Postgres voraus oder empfehlen es sehr klar.

Die technischen Vorteile, die in KMU-Projekten wirklich spürbar sind:

• JSONB: Sie können strukturierte JSON-Dokumente in einer Spalte speichern und trotzdem indiziert abfragen. Für Anwendungen mit halb-flexiblen Datenstrukturen — Konfigurationsobjekte, API-Responses, Log-Aggregation — ist das ein echter Gamechanger und ein häufiger Grund, warum Entwickler-Teams Postgres wählen.
• PostGIS: Vollwertige geografische Extension. Wenn Sie Standortdaten, Routen oder Zonen speichern, ist PostGIS unschlagbar. In MariaDB gibt es GIS-Funktionen, aber der Funktionsumfang liegt weit hinter PostGIS.
• CTEs und Window Functions: Beide Datenbanken beherrschen das inzwischen, aber Postgres hat den Erfahrungsvorsprung — komplexe analytische Abfragen sind lesbarer und der Optimizer geht souveräner damit um.
• Erweiterbarkeit: pg_stat_statements für Query-Analyse, pgvector für Embeddings in KI-Anwendungen, pg_cron für zeitgesteuerte Jobs innerhalb der DB.
• Strengere Standards: Postgres beharrt bei Datentypen und Constraints. Das bewahrt vor Datenmüll, kostet aber Umdenken, wenn Sie aus der MySQL-Welt kommen.

Aktuelle Empfehlung: PostgreSQL 17 für neue Installationen, PostgreSQL 16 als Fallback, wenn Ihre Anwendung noch nicht offiziell 17 unterstützt.

Typische Self-Hosting-Stacks im Direktvergleich

Damit die Entscheidung greifbarer wird — hier ein Überblick über gängige Anwendungen und die pragmatische Empfehlung:

Anwendung	Unterstützung	Unsere Empfehlung	Anmerkung
Nextcloud	MariaDB, PostgreSQL	MariaDB	Doku und Community-Wissen sind MariaDB-lastig
GitLab	nur PostgreSQL	PostgreSQL	keine Wahl — Postgres 14+ erforderlich
Mailcow	MariaDB (fest verdrahtet)	MariaDB	Docker-Compose-Stack bringt MariaDB mit
Odoo	nur PostgreSQL	PostgreSQL	typisch Postgres 15/16
WordPress	MariaDB/MySQL	MariaDB	reines PHP-Ökosystem
Zammad	PostgreSQL empfohlen	PostgreSQL	MySQL-Support wurde eingestellt
Bookstack, Kimai	MariaDB/MySQL	MariaDB	LAMP-Klassiker
Metabase, Grafana	beide, oft SQLite/Postgres	PostgreSQL	für belastbaren Betrieb
Vaultwarden	SQLite Default	PostgreSQL bei Bedarf	für Teams >20 sinnvoll

Die Praxis-Regel: Betreiben Sie beide Systeme parallel, wenn Ihr Stack es verlangt. Zwei LXC-Container auf einem Proxmox-Host mit sauberen Ressourcen-Limits sind kein Problem und trennen die Betriebsverantwortung sauber.

Backup-Strategien für den Ernstfall

Ein DB-Backup ist nur so gut wie der letzte erfolgreiche Restore-Test. Beide Datenbanken bieten robuste Werkzeuge, aber sie unterscheiden sich im Detail.

MariaDB — pragmatische Kombination:

# Tägliches logisches Backup, ideal für <20 GB Datenbanken
mariadb-dump --all-databases --single-transaction \
  --routines --triggers --events \
  | zstd -T0 -19 -o /backup/mariadb-$(date +%F).sql.zst

# Physisches Hot-Backup für größere Instanzen
mariabackup --backup --target-dir=/backup/mariabackup/$(date +%F) \
  --user=backup --password="$BACKUP_PW"
mariabackup --prepare --target-dir=/backup/mariabackup/$(date +%F)

PostgreSQL — Basisstrategie mit Point-in-Time-Recovery:

# Tägliches logisches Backup mit Custom-Format für selektiven Restore
pg_dump -Fc -Z 9 -f /backup/pg-$(date +%F).dump datenbankname

# Physisches Basis-Backup + WAL-Archivierung für PITR
pg_basebackup -D /backup/pg-base/$(date +%F) -Ft -z -P -X stream
# WAL-Archivierung über archive_command in postgresql.conf

Für beide Datenbanken gilt: Legen Sie die Backup-Dumps auf einem TrueNAS-Dataset mit ZFS-Snapshots ab, replizieren Sie diese per zfs send | zfs recv auf ein zweites System, und testen Sie mindestens quartalsweise einen kompletten Restore in einer isolierten LXC-Umgebung. Ohne getesteten Restore existiert das Backup faktisch nicht — eine Erkenntnis, die wir bei Kundenprojekten leider immer wieder frisch bestätigt bekommen.

Für die Absicherung des gesamten DB-Hosts empfehlen wir zusätzlich einen Proxmox-Backup-Server-Job auf den gesamten LXC/VM-Container. Details zu unserer Backup-Architektur besprechen wir gerne im konkreten Projektkontext.

Migration und typische Stolperfallen

Migrationen zwischen den beiden Systemen sind machbar, aber selten “einfach mal so”. Die häufigsten Themen, die wir sehen:

Datentypen: TINYINT(1) als Boolean-Ersatz in MariaDB wird in Postgres zu einem echten BOOLEAN. DATETIME in MariaDB versus TIMESTAMP WITH TIME ZONE in Postgres — letzteres ist strenger und macht Zeitzonen-Bugs sichtbar, die vorher versteckt waren. Das ist gut, kann aber initial für Überraschungen sorgen.

Case-Sensitivity: MariaDB behandelt Tabellen- und Spaltennamen unter Linux case-sensitive, unter Windows nicht — Postgres normalisiert unangeführte Bezeichner zu Kleinbuchstaben. Anwendungscode, der SELECT * FROM Users schreibt, funktioniert plötzlich nicht mehr.

Auto-Increment: MariaDBs AUTO_INCREMENT wird in Postgres zu GENERATED ALWAYS AS IDENTITY (seit Postgres 10 Standard) oder klassisch SERIAL. Wenn Sie Daten migrieren, müssen Sequenzen anschließend auf den korrekten Startwert gesetzt werden.

Tooling: pgloader ist unser bevorzugtes Werkzeug für MySQL/MariaDB → PostgreSQL-Migrationen. Es liest MariaDB direkt, mappt Datentypen sinnvoll und transferiert Daten in einem Rutsch. Für die umgekehrte Richtung existiert kein Standardwerkzeug — Postgres → MariaDB ist deutlich seltener und meist Handarbeit über pg_dump --data-only mit anschließender Datentyp-Konvertierung.

Unser genereller Rat: Migrieren Sie nur, wenn ein konkreter Grund vorliegt (Feature-Bedarf, Anwendungswechsel, Konsolidierung), nicht aus Prinzip. Ein produktives System zu portieren, das seit fünf Jahren stabil läuft, ist ein Projekt mit realem Ausfallrisiko.

Fazit — die richtige Entscheidungsgrundlage

Es gibt keine universell “bessere” Datenbank. MariaDB bleibt die richtige Wahl für PHP-lastige Stacks, Nextcloud, Mailcow und alles im klassischen LAMP-Umfeld. PostgreSQL ist die pragmatische Wahl, sobald Sie GitLab, Odoo, GIS-Funktionalität, JSONB-Datenmodelle oder KI-nahe Anwendungen mit pgvector betreiben. In der Praxis fahren die meisten unserer Kunden mit beiden Systemen parallel — passend zur jeweiligen Anwendung.

Wichtiger als die Wahl der Engine sind: dokumentierte Backup-Strategie mit getesteten Restores, saubere Trennung in eigenen LXC-Containern auf Proxmox, aktuelles Monitoring (Zabbix, Netdata oder Grafana mit mysqld_exporter bzw. postgres_exporter) und ein realistischer Update-Fahrplan für Major-Versionen.

---

DATAZONE unterstützt Sie bei Auswahl, Aufbau und Betrieb Ihrer Self-Hosting-Datenbanken — von der Erstberatung über die Migration bis zum laufenden Backup-Konzept auf Proxmox und TrueNAS. Sprechen Sie uns an: Kontakt aufnehmen.