Wir möchten Ihre Aufmerksamkeit auf diesen ausführlichen Artikel lenken, der auf Praxiserfahrungen basiert und einem selten diskutierten Thema gewidmet ist: der Migration von Firebird zu PostgreSQL.
Der Artikel beleuchtet 23 praxisnahe Probleme, die Teams oft unvorbereitet treffen – etwa warum PostgreSQL einfache Updates 17-mal langsamer ausführen kann als Firebird, weshalb Ihre Backup-Strategie komplett überarbeitet werden muss und warum Sie sämtliche Trigger neu schreiben müssen. Dabei geht es nicht darum, PostgreSQL schlechtzumachen (es ist eine hervorragende Datenbank), sondern darum, DBAs, CTOs und Entwicklern ein klares Bild davon zu geben, worauf sie sich einlassen.
Der Artikel ist auf Englisch, Deutsch und Portugiesisch verfügbar:
Migration from Firebird to PostgreSQL: What can go wrong? – PDF-Version
Migration von Firebird zu PostgreSQL. Was kann schiefgehen? – PDF-Version
Migração do Firebird para PostgreSQL: O que pode dar errado? – PDF-Version
Wir danken allen, die bei der Materialsammlung und der Vorbereitung der Übersetzungen geholfen haben: Dmitry Yemanov, Sergey Volkov, Denis Simonov, Alexey Kovyazin, Martin Köditz und Edson Gregorio.
Wenn Sie eine Datenbankmigration von Firebird zu PostgreSQL oder zu einer anderen Datenbank in Erwägung ziehen, teilen Sie uns bitte Ihre Fragen und Bedenken mit.
Für alle Rückfragen wenden Sie sich gerne an Alexey Kovyazin: ak@firebirdsql.org
Originaltext erschienen unter: https://firebirdfoundation.substack.com ... m-firebird
Neuer Artikel: Migration von Firebird zu PostgreSQL. Was kann schiefgehen?
Moderator: martin.koeditz
-
martin.koeditz
- Beiträge: 535
- Registriert: Sa 31. Mär 2018, 14:35
Martin Köditz
SynDesk SW GmbH
SynDesk SW GmbH
Eine sehr gute Erklärung für die unterschiedlichen Arbeitsweisen dieser 2 DBMS.
Erschreckend für mich ist nicht die Tatsache der Inkompatibiltäten der SQL's sondern dass es eine kommerzielle Postgre überhaupt gibt und diese auch nun für Windows nicht mehr verfügbar ist.
Ich dachte Postgre wir durch die Community, ähnlich Firebrid, gefördert.
Viele DBMS haben je Tabelle und Index je eine eigene Datei im Dateisystem was bei der Firebird eben nicht der Fall ist. Und wenn der Aufwand im Gegensatz zum Nutzen auch noch durch notwendige finanzielle Aufwände in eine Pro-Version mit Linux-Server erfolgen muss, sollte man von solchen Projekten wirklich Abstand nehmen.
Wir wurden des öfteren schon gefragt, ob wir nicht auf SQL-Server umstellen können, da man diesen bereits "im Haus" hätte.
Aber wie im o.a. Dokument erwähnt benutze ich häufig einen Execute-Block sowie auch innerhalb dessen bis zu 255 parametrierte Update or Insert (beschränkt halt auf die 10MB und max. 2000 Parametern).
Damit schafft man schon mal 10.000 bis 30.000 Inserts/Sekunde statt 2000/Sekunde mit Einzelausführungen.
255 deshalb, weil SQL max. 255 Tabellen verarbeiten kann, auch wenn es immer dieselbe ist.
Vorteile des Update or Inserts ist auch die Wiederholbarkeit innerhalb eines Massenladens.
Der SQL-Server Merge bietet zwar ähnliches an, allerdings wird ein 2. Update über denselben Schlüssel mit einem Transaktionsabbruch "doppelter Update" quittiert, also nicht hilfreich.
Auch die Satzversionen sind ein essentieller Bestandteil von ETL-Prozessen, die natürlich schon mal länger dauern können und auch mal per rollback abgebrochen werden müssen.
So wird dann ein "Delete from Table" und Massen Insert in einer Transaktion durchgeführt. Bei Abbruch, egal aus welchen Gründen, sind die vorherigen Daten halt weiter verfügbar.
Bei der PostGre kann ich das auf den ersten Blick nicht erkennen.
Vieles spricht also dafür, bei Firebird zu bleiben, weil letztlich die Haupt-Vorteile Einzeldatei und kostenlos überwiegen.
Erschreckend für mich ist nicht die Tatsache der Inkompatibiltäten der SQL's sondern dass es eine kommerzielle Postgre überhaupt gibt und diese auch nun für Windows nicht mehr verfügbar ist.
Ich dachte Postgre wir durch die Community, ähnlich Firebrid, gefördert.
Viele DBMS haben je Tabelle und Index je eine eigene Datei im Dateisystem was bei der Firebird eben nicht der Fall ist. Und wenn der Aufwand im Gegensatz zum Nutzen auch noch durch notwendige finanzielle Aufwände in eine Pro-Version mit Linux-Server erfolgen muss, sollte man von solchen Projekten wirklich Abstand nehmen.
Wir wurden des öfteren schon gefragt, ob wir nicht auf SQL-Server umstellen können, da man diesen bereits "im Haus" hätte.
Aber wie im o.a. Dokument erwähnt benutze ich häufig einen Execute-Block sowie auch innerhalb dessen bis zu 255 parametrierte Update or Insert (beschränkt halt auf die 10MB und max. 2000 Parametern).
Damit schafft man schon mal 10.000 bis 30.000 Inserts/Sekunde statt 2000/Sekunde mit Einzelausführungen.
255 deshalb, weil SQL max. 255 Tabellen verarbeiten kann, auch wenn es immer dieselbe ist.
Vorteile des Update or Inserts ist auch die Wiederholbarkeit innerhalb eines Massenladens.
Der SQL-Server Merge bietet zwar ähnliches an, allerdings wird ein 2. Update über denselben Schlüssel mit einem Transaktionsabbruch "doppelter Update" quittiert, also nicht hilfreich.
Auch die Satzversionen sind ein essentieller Bestandteil von ETL-Prozessen, die natürlich schon mal länger dauern können und auch mal per rollback abgebrochen werden müssen.
So wird dann ein "Delete from Table" und Massen Insert in einer Transaktion durchgeführt. Bei Abbruch, egal aus welchen Gründen, sind die vorherigen Daten halt weiter verfügbar.
Bei der PostGre kann ich das auf den ersten Blick nicht erkennen.
Vieles spricht also dafür, bei Firebird zu bleiben, weil letztlich die Haupt-Vorteile Einzeldatei und kostenlos überwiegen.
-
martin.koeditz
- Beiträge: 535
- Registriert: Sa 31. Mär 2018, 14:35
Ja, das ist ein aktuelles Thema bei uns. Läuft "unerwartet" auch nicht schneller...Wir wurden des öfteren schon gefragt, ob wir nicht auf SQL-Server umstellen können, da man diesen bereits "im Haus" hätte.
Martin Köditz
SynDesk SW GmbH
SynDesk SW GmbH
Warum auch, da gibts halt so physikalische Grenzen, die auch Microsoft nicht umgehen kann.
Zumal die Datenbanken mangels Komprimierung auch größer sind und deshalb mehr von der Platte zu lesen ist.
Ein großes Problem habe ich da bei Transaktionen.
Wenn ich für den ETL einen synchronen Load (Read committed) einer Tabelle benötige, kommt das Thema LockEscalation ins Spiel, dass zum Schluss die gesamte Tabelle sperrt und ein ERP zum Stillstand bringen kann.
Immerhin lädt man bei ETL schon mal eine ganze Tabelle herunter.
Bei Lesegeschwindigkeiten von ca. 30.000 Zeilen/Sekunde dauern 1 Mio. Zeilen auch schon mal 30 Sekunden.
Bei der Firebird habe ich das Problem erst gar nicht, da ich neuerer Transaktionen sowieso nicht sehe.
Zumal die Datenbanken mangels Komprimierung auch größer sind und deshalb mehr von der Platte zu lesen ist.
Ein großes Problem habe ich da bei Transaktionen.
Wenn ich für den ETL einen synchronen Load (Read committed) einer Tabelle benötige, kommt das Thema LockEscalation ins Spiel, dass zum Schluss die gesamte Tabelle sperrt und ein ERP zum Stillstand bringen kann.
Immerhin lädt man bei ETL schon mal eine ganze Tabelle herunter.
Bei Lesegeschwindigkeiten von ca. 30.000 Zeilen/Sekunde dauern 1 Mio. Zeilen auch schon mal 30 Sekunden.
Bei der Firebird habe ich das Problem erst gar nicht, da ich neuerer Transaktionen sowieso nicht sehe.
Hallo, hier mal ein kleiner Erfahrungsbericht zu einer abgeschlossenen Migration von Firebird nach Postgres.
Um es gleich vorweg zu sagen: Es geht mir nicht darum dem ziemlich informativen Artikel um Ursprungspost zu widersprechen,
sondern darum die Datenbasis etwas zu erweitern, falls jemand vor der Entscheidung steht von FB zu PG zu migrieren oder nicht.
Ausgangssituation:
Ein Projekt das seit ca 15 Jahren auf Firebird lief, zuletzt unter Version 3.
Datenbank mit ca 1.8 TB, die umfangreicheren Tabellen mit 100M+ Zeilen.
Relativ dynamische Situation wo auch Einiges wieder gelöscht wird, so dass bei einzelnen Tabellen
die fortlaufende Id den 32bit Wertebereich schon seit Längerem verlassen hat.
Auslöser über eine Migration nachzudenken waren Performanceprobleme,
die ab einer bestimmten DB-Größe in Erscheinung traten.
Z.B hat ein simpler Query wie: SELECT * from CURVE where id = 3 eine Laufzeit von mehr als 30 Sekunden.
Der gleiche Query auf dem Test-System läuft mit < 1s. Wesentlicher Faktor bei dieser Sache schienen Spalten mit Binärdaten zu sein.
Migration:
Schema export und import mit Hilfe von Liquibase
Anpassung des exportierten Schemas, Daten-Export zu CSV, Daten-import und Validierung mit Hilfe von Python.
Ergebnis:
Postgres ist wesentlich komplexer zu administrieren.
Das dürfte an sich klar sein und ist in unserem Projekt akzeptabel.
Es ist bis jetzt aber auch der einzige Nachteil der sich in der Praxis bemerkbar gemacht hat.
Bezüglich Geschwindigkeit hatten wir erwartet, dass die beiden Datenbanken im Wesentlichen gleich ziehen und
hatten erstmal nur erhofft die oben geschilderten punktuellen Probleme los zu werden.
Es zeigt sich allerdings, dass in unserem Fall eine generelle Beschleunigung erreicht wurde.
Ich hänge zwei Bilder an.
Das Eine zeigt eine Auswertung auf unserem Testsystem auf Querylevel. Grüne Felder zeigen wo Postgres schneller ist als Firebird, Rote Felder wo Postgres langsamer ist als Firebird. (Ich empfehle vor allem die linke Seite anzuschauen, weil dieser Report nicht speziell für diesen Beitrag hier erzeugt wurde und auf der rechten Seite optimierte Queries unter Postgres mit unoptimierten unter Firebird verglichen werden)
Das Andere zeigt akkumulierte Laufzeiten in CPU-Sekunden auf unserem Produktiv-System vor und nach der Umstellung.
Umstellung war 2026-02-14. Berechnungen für diesen Tag wurden am 16. nachgeholt, deswegen fällt der 16. etwas aus dem Rahmen was die Berechnungszeit angeht.
Ingesamt ist also für unseren spziellen Fall eine Beschleunigung um den Faktor 3-4 entstanden, die so nicht unbedingt erwartet war.
Um es gleich vorweg zu sagen: Es geht mir nicht darum dem ziemlich informativen Artikel um Ursprungspost zu widersprechen,
sondern darum die Datenbasis etwas zu erweitern, falls jemand vor der Entscheidung steht von FB zu PG zu migrieren oder nicht.
Ausgangssituation:
Ein Projekt das seit ca 15 Jahren auf Firebird lief, zuletzt unter Version 3.
Datenbank mit ca 1.8 TB, die umfangreicheren Tabellen mit 100M+ Zeilen.
Relativ dynamische Situation wo auch Einiges wieder gelöscht wird, so dass bei einzelnen Tabellen
die fortlaufende Id den 32bit Wertebereich schon seit Längerem verlassen hat.
Auslöser über eine Migration nachzudenken waren Performanceprobleme,
die ab einer bestimmten DB-Größe in Erscheinung traten.
Z.B hat ein simpler Query wie: SELECT * from CURVE where id = 3 eine Laufzeit von mehr als 30 Sekunden.
Der gleiche Query auf dem Test-System läuft mit < 1s. Wesentlicher Faktor bei dieser Sache schienen Spalten mit Binärdaten zu sein.
Migration:
Schema export und import mit Hilfe von Liquibase
Anpassung des exportierten Schemas, Daten-Export zu CSV, Daten-import und Validierung mit Hilfe von Python.
Ergebnis:
Postgres ist wesentlich komplexer zu administrieren.
Das dürfte an sich klar sein und ist in unserem Projekt akzeptabel.
Es ist bis jetzt aber auch der einzige Nachteil der sich in der Praxis bemerkbar gemacht hat.
Bezüglich Geschwindigkeit hatten wir erwartet, dass die beiden Datenbanken im Wesentlichen gleich ziehen und
hatten erstmal nur erhofft die oben geschilderten punktuellen Probleme los zu werden.
Es zeigt sich allerdings, dass in unserem Fall eine generelle Beschleunigung erreicht wurde.
Ich hänge zwei Bilder an.
Das Eine zeigt eine Auswertung auf unserem Testsystem auf Querylevel. Grüne Felder zeigen wo Postgres schneller ist als Firebird, Rote Felder wo Postgres langsamer ist als Firebird. (Ich empfehle vor allem die linke Seite anzuschauen, weil dieser Report nicht speziell für diesen Beitrag hier erzeugt wurde und auf der rechten Seite optimierte Queries unter Postgres mit unoptimierten unter Firebird verglichen werden)
- Screenshot 2026-02-18 103644.png (170.7 KiB) 1585 mal betrachtet
- Screenshot 2026-02-18 105438.png (66.43 KiB) 1585 mal betrachtet
Ingesamt ist also für unseren spziellen Fall eine Beschleunigung um den Faktor 3-4 entstanden, die so nicht unbedingt erwartet war.
-
martin.koeditz
- Beiträge: 535
- Registriert: Sa 31. Mär 2018, 14:35
Vielen Dank für deine umfrangreichen Ergebnisse.
Interessant wäre natürlich der Vergleich mit einer aktuellen Firebird-Version gewesen. Ich gehe davon aus, dass du eine aktuelle Postgres-Version verwendest? Die Gegenüberstellung mit einer 10 Jahre alten Engine "hinkt" dann natürlich etwas.
Trotzdem: sehr spannende Infos.
Gruß
Martin
Interessant wäre natürlich der Vergleich mit einer aktuellen Firebird-Version gewesen. Ich gehe davon aus, dass du eine aktuelle Postgres-Version verwendest? Die Gegenüberstellung mit einer 10 Jahre alten Engine "hinkt" dann natürlich etwas.
Trotzdem: sehr spannende Infos.
Gruß
Martin
Martin Köditz
SynDesk SW GmbH
SynDesk SW GmbH