Warum PostgreSQL

Hallo Forum,
ich habe ein größeres Projekt das zur Zeit noch mit der MySQL-Datenbank läuft.
Das Projekt muss überarbeitet und modernisiert werden. Bei meiner Suche nach einem geeignetem Datebanksystem bin ich immer wieder auf PostgreSQL und MSSQL gestoßen. Wenn man mal von den Kosten des MSSQL absieht, hat PóstgreSQL noch andere Vorteile? Warum nutzt ihr PostgeSQL
Das würde mich wirklich interessieren.
Danke und LG

Auf SQL Ebene finde ich Postgres wesentlich leichter und flexibler zu verwenden als SQL Server. String und Datums Funktionen sind wesentlich mächtiger (das wurde mit SQL Server 2019 ein wenig besser), außerdem hat SQL Server keine Unterstützung für richtige reguläre Ausdrücke (nur Etwas verkrüppeltes mit einem nicht-standard LIKE Operator).

Grundsätzlich ist es mir auch sympathischer, dass Postgres Wert darauf legt, sich an den SQL Standard zu halten. SQL Server ignoriert den vielfach schon für Kleinigkeiten.

Foreign keys werden bei Postgres besser unterstützt (deferred constraints, sowie “ON CASCADE” Option auch für foreign keys die die gleiche Tabelle referenzieren)

Postgres hat auch wesentlich mehr Datentypen zur Auswahl. Z.b. einen echten boolean Typ, und damit auch Unterstützung für echte bool’sche Ausdrücke ausserhalb der WHERE Bedingung. Zudem auch Intervalle und Range types.

DDL ist auch wesentlich “einfacher”. Fast alle Befehle haben eine IF EXISTS oder IF NOT EXISTS Option mit der sich idempotente Anweisungen schreiben lassen. DROP kennt eine CASCADE Option mit der automatisch foreign key constraints gelöscht werden - man muss nicht umständlich manuell all FKs selber löschen.

TRUNCATE kann auch mit Tabellen mit Foreign Keys arbeiten.

SQL Funktionen bieten mehr Möglichkeiten, z.B. kann man in Postgres in einer Funktion dynamic SQL verwenden. Bei SQL Server geht das nur wenn man Funktionen in C# (oder anderen CLR Sprachen) schreibt.

Was ein wenig nervt in Postgres ist die Tatsache, dass man Tabellen die in Views verwendet werden, nicht so einfach ändern kann (Spalten umbenennen, Datentyp ändern). Alle Views in Postgres verhalten sich so wie Views in SQL Server die mit der Option “WITH SCHEMABINDING” angelegt werden. Wenn man das vorher weiß, kann man aber die Skripte für die Schema Migrationen entsprechend strukturieren und dann ist das eigentlich nicht so schlimm.

Der JSON Support scheint mir bei Postgres auch besser zu sein (ich kenne die SQL Server Möglichkeiten dort aber nicht wirklich im Detail) z.B. kann ich dort eine gesamte Spalte indizieren und der Index kann für viele verschiedene Abfragen verwendet werden. Bei SQL Server kann ich genau einen festen Ausdruck indizieren.

Ich habe nie wirklich mit den “Geo/Spatial” Möglichkeiten in beiden Datenbanken gearbeitet. Aber viele Leute berichten, dass PostGIS den kommerziellen Datenbanken weit überlegen ist.

Bei den DBA und Monitoring Möglichkeiten hat SQL Server (zumindest in der Enterprise Version) wohl noch ein wenig die Nase vorn. Es ist wie so oft im Vergleich kommerziell vs. OpenSource: beim kommerziellen Produkt bekommst Du alles aus einer Hand, musst nicht suchen und es passt zusammen (hast aber auch selten überhaupt Wahlmöglichkeiten). Bei den OpenSource Produkten gibt es meistens zwei oder drei Auswahlmöglichkeiten für bestimmte Tools oder Funktionen - da muss man ein wenig suchen und ausprobieren was für den eigenen Einsatzzweck am besten geeignet ist.

Kommerziellen Support gibt es auch für Postgres. Viele der Firmen die den anbieten, arbeiten aktiv an Postgres mit und können so, bei (den seltenen) Bugs auch selber aktiv werden und sind nicht darauf beschränkt das nur an den Hersteller melden zu können.

Man sollte auch nicht unterschätzen welche Hilfe die Mailinglisten (kostenlos!) bieten. Ich habe im Lauf der Zeit vielleicht 2 oder 3 echte Bugs gemeldet und im Regelfall kam ein bis zwei Tage später eine Mail “ich habe einen Fix committed, wenn Du willst kannst Du mal eine Version selber bauen und ausprobieren”. Zum Vergleich: ich habe in den Oracle Foren drei zweifelsfreie Bugs im JDBC Treiber gemeldet (wir haben keinen Supportvertrag), zwei davon haben klar gegen das von der JDBC Spezifikation geforderte Verhalten verstoßen. Oracle hat gemeint (sinngemäß), dass wären keine Bugs und die Spezifikation (die sie selber schreiben) wäre eh egal. Keine Ahnung ob Microsoft da besser gewesen wäre.

Bei richtig, richtig, großen Datenbanken (zig TB) und Datawarehouse Anwendungen scheint SQL Server mit den In-Memory und Column-Store Optionen die Nase vorn zu haben - allerdings auch wieder nur in der Enterprise Version, wenn ich das richtig im Kopf habe. Andererseits gibt’s da mit der Citus Extension für Postgres ähnliche Möglichkeiten (die im Übrigen von Microsoft entwickelt wird)

Langer Rede kurzer Sinn: ich persönlich kenne keinen triftigen Grund der für SQL Server und gegen Postgres sprechen würde - vor allem nicht wenn ihr für keines der beiden System Know-How im Haus habt.

WOW erstmal Danke für die detaillierte Antwort.
Also richtiges Know How ist im Haus tatsächlich nicht vorhanden was die beiden DBMS angeht.
Für mich ist stabilität und Performance entscheidend vor allem wenn es um viele Daten und komplexen SQLs angeht.
Die MySQL-DB ist > 450GB mit vielen Blobs und > 5 Mio Datensätze

Da liegst Du mit Postgres auf keinen Fall falsch.

“Performance” ist natürlich immer so ein Ding. Ich kann immer Abfragen finden die in System A schneller sind als in System B. Und dann Abfragen die in System B schneller sind als in System A.

Wichtig ist, dass man sich bei so einer Migration auf das Zielsystem einlässt und Dinge so macht wie sie mit dem System am besten gemacht werden. Mit der Einstellung “So haben wir das mit XYZ aber auch immer gemacht” kommt man nicht weit. Eine Implementierung die in SQL Server effizient läuft kann auf Oracle oder Postgres extrem schlecht laufen. Andererseits kann es aber auch sein, dass die Herangehensweise die eine Anwendung unter Postgres oder Oracle sehr schnell macht unter SQL Server dazu führt, dass nix mehr geht.

Tabellen 5 Mio Datensätzen werden heutzutage eher als “klein” angesehen.

BLOBs (binary large objects) werden übrigens in Postgres am besten in bytea Spalten gespeichert. Vergiss die “large objects”.

Bei einer Migration kann man häufig “komplexe SQLs” auch vereinfachen. Vor allem auf dem Weg von MySQL nach Postgres. Postgres bietet wesentlich mehr Features als MySQL und vieles was man dort umständlich “simulieren” musste, geht vielleicht wesentlich einfacher in Postgres (MySQL hat mit 8.x ein wenig aufgeholt, aber der Abstand ist immer noch da).

Ich kann @castorp nur zustimmen (wie auch im anderen Forum …). 450GB und 5 Millionen Datensätze sind eher geringe Anforderungen an PG.

Ergänzend zu @castorp noch:

  • Tabellen immer mit einem PK anlegen
  • korrekte Datentypen verwenden, PG hat MASSIG Datentypen
  • schaut Euch an, was es für Indexmöglichkeiten gibt, MySQL kennt z.B. keine funktionalen und partielle Indexe, wir haben solche und es gibt versch. Indextypen (BTREE, GIN, GiST, BRIN etc)
  • die originale postgresql.conf ist sehr konservativ, andererseits sind es nur relativ wenige Parameter, an denen zu optimieren ist
  • PG hat ein sehr aussagekräftiges EXPLAIN
  • die Doku ist eine super Referenz für alles, allerdings nicht als Lehrbuch geeignet
  • PG hat eine super Community, die sehr hilfreich auch Anfänger unterstützt
  • Firmen wie wir (2ndQuadrant) haben oft auch gute Blogs, siehe https://www.2ndquadrant.com/en/blog/

Ja, das so mal noch als Gedanken …

Was mir dazu noch einfällt: die Kosten mögen am Anfang ja noch überschaubar sein. Aber dann wächst eure Anwendung und ihr müsst einen stärkeren Server nehmen der mehr CPUs hat - dafür wird euch Microsoft zur Kasse bitten.

Dann wollt ihr Ausfallsicherheit und müsst einen zweiten Server hinstellen → dafür fallen wieder neue Lizenzkosten an. Möglicherweise fallen auch zusätzliche Kosten für die damit verbundene Replikation an (ich kenne das Microsoft Lizenzmodell nicht so genau aber bei Oracle wäre das z.B. der Fall)

Dann wollt ihr einen eigenen Server für’s Reporting. Dann ist eine weitere Lizenz für SQL Server fällig. Dann wird der Reporting Server zu klein und ihr steckt mehr CPUs rein… (usw. usw)

1 „Gefällt mir“