mySQL oder PostgreSQL?

Bisher Mariadb, werde aber demnächst mal PostgreSQL testen.

Hab das neulich mal mit Chatgpt diskutiert :

Zitat :

Kurz gesagt: Wenn du mit MariaDB gut klarkommst, musst du nicht wegen eines Trends wechseln. Für viele private Projekte ist MariaDB völlig solide.

Warum trotzdem so viele bei neuen Web-Apps zu PostgreSQL greifen:

Wo PostgreSQL stark ist

1) JSON / semi-strukturierte Daten → richtig gut

Postgres hat mit JSONB ein starkes Feature.

Beispiel Consumer-App:
User-Profil:

Das kannst du direkt in einer Spalte speichern und performant durchsuchen/indexieren.

Beispiel:

Für:

• Preferences
• Feature Flags
• flexible Metadaten
• Search-Filter
• App Config

…super praktisch.

MariaDB kann JSON auch, aber Postgres ist hier oft angenehmer und breiter genutzt.

2) Erweiterungen / Ökosystem

Sehr starkes Extension-System.

Beliebt:

• PostGIS → Geo Features / Maps
• pgvector → Vector Search / AI Features
• Full Text Search
• trigram search (fuzzy search)

Beispiel:

Quote

„ähnliche Beiträge finden“
„Semantik-Suche“
„Orte in 5 km Radius“

→ Postgres fühlt sich dafür natürlicher an.

3) Strenger / konsistenter

Postgres ist oft etwas strikter bei Typen und SQL-Verhalten.

Am Anfang manchmal nervig.

Langfristig:
→ weniger komische Edge Cases.

Viele Entwickler mögen genau das.

4) Viele moderne Tools optimieren dafür

Viele Tools sind zuerst auf Postgres fokussiert:

z. B.:

• Supabase
• Prisma
• SQLAlchemy
• Drizzle ORM
• Auth Libraries
• Vector DB Integrationen

MariaDB läuft oft auch — aber manchmal nicht first-class.

Wo MariaDB stark bleibt

Für deine Art Projekte:

MariaDB ist top bei:
✅ klassische CRUD Apps
✅ User/Auth
✅ Blog / CMS
✅ kleine SaaS Ideen
✅ Admin Panels
✅ APIs
✅ Docker local dev
✅ performant
✅ stabil
✅ du kennst es bereits

Und Know-how schlägt theoretische Vorteile ziemlich oft.

Ich nutze hauptsächlich PostgreSQL. Anfangs (2015 rum) nutzte ich noch MySQL aber all die Vorteile von PostgreSQL und Erfahrungen der Community im Internet, haben mich all die Jahre zu PostgreSQL gebracht.

Gemini (Thinking-Modus): "Erkläre mir die wichtigsten Unterschiede zwischen MySQL und PostgreSQL - Warum wird was von der Community bevorzugt?"

Zudem finde ich alleine die Erweiterbarkeit von PostgreSQL unschlagbar. Ich benötige zum Beispiel eine Suche, die es mir ermöglicht nach "ifone" zu suchen und "iPhone" zu erhalten - Ich verwende "pg_trgm", welche mit einer Zeile CREATE EXTENSION IF NOT EXISTS pg_trgm; zum Projekt hinzugefügt wird.

Gemini (Thinking-Modus): "Wie sieht es mit Extensions wie "pg_trgm" für PostgreSQL aus?"

Quote

Die Extension pg_trgm (Trigram) ist einer der Gründe, warum PostgreSQL oft als „die Datenbank, die alles kann“ bezeichnet wird. Sie ist ein perfektes Beispiel für die Erweiterbarkeit von Postgres, während MySQL in diesem Bereich eher auf spezialisierte (aber unflexiblere) Bordmittel setzt.

Hier ist, warum pg_trgm so ein „Game-Changer“ für die Community ist:

1. Was macht pg_trgm eigentlich?

Die Extension zerlegt Texte in Trigramme – das sind Sequenzen von drei aufeinanderfolgenden Zeichen.

• Beispiel: Das Wort „Apfel“ wird intern etwa so zerlegt: {" a"," ap","apf","pfl","fel","el "}.

Die zwei Superkräfte der Extension:

1. Ähnlichkeits-Suche (Fuzzy Search): Sie berechnet, wie viele Trigramme zwei Texte teilen. Wenn ein User „Apfel“ sucht, aber „Apfbel“ tippt, findet Postgres das Ergebnis trotzdem, weil die Schnittmenge der Trigramme sehr hoch ist.
2. Der Index-Turbo für LIKE: Normalerweise kann eine Datenbank einen Index nur nutzen, wenn du nach LIKE 'Anfang%' suchst. Wenn du aber nach LIKE '%Ende%' suchst (Wildcard am Anfang), muss MySQL die komplette Tabelle scannen. Postgres mit pg_trgm kann auch das indizieren.

Feature	PostgreSQL (pg_trgm)	MySQL (Standard)
Tippfehler-Toleranz	Exzellent. Findet „iPhone“, wenn man „ifone“ sucht (basierend auf Zeichen-Ähnlichkeit).	Begrenzt. Nutzt meist SOUNDEX, was nur nach dem Klang geht (phonetisch), aber bei Tippfehlern oft scheitert.
Teilstring-Suche	Indizierbar. Suchanfragen wie LIKE '%xyz%' sind dank GIN/GiST-Index extrem schnell.	Langsam. Führt bei großen Tabellen zu einem Full Table Scan (kein Index-Support für führende Wildcards).
Ranking	Gibt einen Score (0 bis 1) zurück, wie gut der Treffer passt.	MySQL Full-Text Search kann ranken, ist aber auf ganze Wörter fixiert, nicht auf Zeichenfolgen.

Hängt ja letztendlich auch von der jeweiöigen Anwendung und dessen DB-Unterstützung ab.

Bin primär noch mit MariaDB unterwegs. Für ein zwei Apps läuft aber auch eine PG DB.

Diese Antwort ist ohne KI entstanden. 😜

Quote from DerRené

Hängt ja letztendlich auch von der jeweiöigen Anwendung und dessen DB-Unterstützung ab.

Bin primär noch mit MariaDB unterwegs. Für ein zwei Apps läuft aber auch eine PG DB.

Diese Antwort ist ohne KI entstanden. 😜

Das glaube ich jetzt einfach mal, schliesslich würde eine KI nie lügen.

Kommt auf den Anwendungsfall an, prinzipiell bevorzuge ich PostgreSQL - insbesonders mit den JSON(B) Columns und dessen Funktionen ist es bei unstrukturierten Daten ein Traum.

Leider sind vorallem im Webbereich viele Anwendungen auf MySQL/MariaDB ausgelegt, weshalb man meist leider nicht um eine MariaDB/MySQL Instanz rumkommt. Daher nutzte ich leider immer noch viel zu oft MariaDB statt PostgreSQL.

ich benutze nur postgres, weil ich solche sachen nicht mag:

MariaDB [test]> select * from test;
+------+
| i    |
+------+
|    1 |
|    1 |
+------+
2 rows in set (0.001 sec)

MariaDB [test]> delete from test where 'wieso_wieso';
Query OK, 0 rows affected, 2 warnings (0.001 sec)

MariaDB [test]> select * from test;
+------+
| i    |
+------+
|    1 |
|    1 |
+------+
2 rows in set (0.001 sec)

MariaDB [test]> delete from test where '1wieso_wieso';
Query OK, 2 rows affected, 2 warnings (0.002 sec)

MariaDB [test]> select * from test;
Empty set (0.001 sec)

ich erwarte nicht das bei so einem statement rows gelöscht werden, das oben war übrigens mit mariadb 11.8, neu gestarteter docker container
(und das problem ist nicht neu, es existiert schon seehr vielen jahren, ich kenne es seit 2019, kein ahnung wie alt das ist)

was für die LOC gut genug ist reicht mir auch.
SQLite Is a Library of Congress Recommended Storage Format

https://sqlite.org/locrsf.html

mariadb und postgres ist nicht erlaubt?

Ich nutze das was meine Docker Services wollen, tendiere aber eher zu PostgresSQL.
Hab mich aber nie mit den Vor-/Nachteilen auseinander gesetzt.

Ich habe einen Galera-Cluster (mariadb)*.
Damit läuft bei mir alles, was vernünftig MySQL/MariaDB spricht.

Alles was nicht (oder unvollständig) mit MySQL/MariaDB umgehen kann, kommt in einen Container mit PostgeSQL sidecar.
(Dann ohne HA)

*) Der Cluster war damals mit PostgreSQL nicht in gleicher Qualität umsetzbar.

Quote from Borgqueen

Verwendet Ihr bei Nextcloud MaridDB

In der Firma: MariaDB (als Galera-Cluster mit mehreren Hosts) mit einigen Tausend Nextcloud Usern. Läuft.

Privat: sqlite dient nur zum Testen...

Quote from Mordor

Ich habe einen Galera-Cluster (mariadb)*.

...
*) Der Cluster war damals mit PostgreSQL nicht in gleicher Qualität umsetzbar.

Ich finde immer noch, dass Multi-Master Clustering mit Galera einfacher klappt, da alles in MariaDB nativ umgesetzt ist.

Mit PostgreSQL hat man eingebaut nur die Möglichkeit an ein read-only Replica zu streamen - für alles weiter braucht es zusätzliche Dienste. Patroni ist recht vielseitig, braucht aber noch zusätzlich ein etcd Cluster.

Quote from stz

ich benutze nur postgres, weil ich solche sachen nicht mag:

ich erwarte nicht das bei so einem statement rows gelöscht werden, das oben war übrigens mit mariadb 11.8, neu gestarteter docker container
(und das problem ist nicht neu, es existiert schon seehr vielen jahren, ich kenne es seit 2019, kein ahnung wie alt das ist)

Ist kein Problem sondern ein gewolltes Feature, das Verhalten kann aber per Konfiguration des "sql_mode" angepasst werden.

Quote from Borgqueen

Verwendet Ihr bei Nextcloud MaridDB oder PostgreSQL?

das was in nextcloud-aio dabei ist.