Webserver & Dienste

Oracle nach PostgreSQL migrieren: So planst du den Umstieg

Die Datenmigration ist selten das Problem, PL/SQL und die daran hängenden Anwendungen sind es. Rechne den Aufwand ehrlich am Anteil der Stored Procedures hoch, nicht an der Datenmenge, sonst kippt die Planung im ersten Projektdrittel.

6 Kapitel mit allen Befehlen
Administrator konfiguriert einen Webserver am Laptop
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team
Worum es geht

Warum die Oracle-Ablösung selten am Schema scheitert, sondern am Code

In den meisten Häusern beginnt das Thema nicht in der Technik, sondern in der Beschaffung. Die jährlichen Lizenz- und Supportkosten stehen im Budget, ein License-Review kündigt sich an, und plötzlich steht die Frage im Raum, welche Datenbanken wirklich Oracle brauchen und welche auf PostgreSQL laufen könnten. Eine Antwort für die ganze Landschaft gibt es nicht: Eine reine OLTP-Anwendung mit weitgehend standardisiertem SQL ist ein anderer Fall als ein gewachsenes System mit PL/SQL-Packages, Oracle Text, Advanced Queuing oder Jobs aus DBMS_SCHEDULER.

Der Schemateil ist dabei der einfachere. Tabellen, Constraints, Indizes und Sequenzen lassen sich mit ora2pg weitgehend automatisch übersetzen, inklusive Typ-Mapping von NUMBER auf numeric oder bigint und von VARCHAR2 auf text. Der eigentliche Aufwand steckt in der Logik. PL/SQL-Packages haben in PostgreSQL kein direktes Gegenstück, Package-Variablen mit Sessionzustand musst du anders lösen, autonome Transaktionen fehlen im Kern, und Hierarchieabfragen mit CONNECT BY wollen als rekursive CTE neu geschrieben werden. ora2pg schätzt den Aufwand dafür, ersetzt aber kein Code-Review.

Drei Fehler siehst du immer wieder. Erstens wird die Anwendung vergessen, obwohl ROWNUM, NVL, DECODE, Abfragen gegen DUAL und Oracle-eigene Treiberdetails oft direkt im Applikationscode stecken. Zweitens wird das Verhalten unterschätzt: PostgreSQL behandelt einen Leerstring nicht wie NULL, sortiert abhängig von der Collation anders und arbeitet mit MVCC ohne Undo-Segmente, was Vacuum und Autovacuum zu einem echten Betriebsthema macht. Drittens fehlt der Rückweg. Wer ohne Parallelbetrieb, Datenabgleich und definiertes Fallback-Fenster umschaltet, hat im Fehlerfall keine Option mehr.

Miniatur-Szene: Webserver-Turm mit umkreisendem Globus, ein- und ausgehende Anfragepfeile, Zertifikatskarte
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Migrationspfad von Oracle zu PostgreSQL

  1. 01 Assessment mit ora2pg-Report
  2. 02 Schema und Typ-Mapping
  3. 03 PL/SQL zu PL/pgSQL
  4. 04 Datenübernahme und Abgleich
  5. 05 Pläne und Tuning
  6. 06 Parallelbetrieb und Cutover
Was du mitnimmst

Der Migrationsweg in klaren Etappen

Eine Migration wird beherrschbar, wenn du sie nicht als ein Ereignis behandelst, sondern als Kette von Schritten mit jeweils eigenem Abnahmekriterium. Diese Reihenfolge hat sich in Projekten bewährt und lässt sich auf einzelne Schemas genauso anwenden wie auf eine ganze Instanz.

Bestand und Machbarkeit bewerten

Lass ora2pg im Report-Modus über das Schema laufen und schau dir die Aufwandsschätzung pro Objekttyp an. Views, Trigger, Packages, externe Tabellen und Datenbank-Links bekommen dabei sehr unterschiedliche Gewichte. Das Ergebnis ist deine Priorisierung: Welches Schema migrierst du zuerst, welches bleibt vorerst auf Oracle.

Schema und Datentypen sauber abbilden

Beim Typ-Mapping entscheidest du bewusst statt automatisch. NUMBER ohne Skalierung wird je nach Wertebereich zu bigint oder numeric, DATE zu timestamp, CLOB zu text. Sequenzen, Identity-Spalten und Default-Werte prüfst du einzeln, ebenso Index-Typen, denn ein Function-Based Index heißt in PostgreSQL Ausdrucksindex und braucht eine als IMMUTABLE markierte Funktion.

PL/SQL nach PL/pgSQL portieren

Packages löst du üblicherweise in Schemas mit einzelnen Funktionen auf, Sessionzustand ersetzt du durch temporäre Tabellen oder Konfigurationsparameter. Autonome Transaktionen bildest du über dblink oder eine Hintergrundverarbeitung ab, CONNECT BY über WITH RECURSIVE. Für Bulk-Logik lohnt der Blick auf mengenbasiertes SQL, weil zeilenweise Cursor in PostgreSQL selten die beste Wahl sind.

Daten übertragen und verifizieren

Für den Erstimport nutzt du COPY statt einzelner INSERTs, ora2pg kann den Export parallelisieren. Anschließend gleichst du ab: Zeilenzahlen pro Tabelle, Prüfsummen über fachliche Schlüssel und Stichproben bei Zahlen, Zeitzonen und Zeichenkodierung. Erst danach legst du Indizes und Constraints an und lässt ANALYZE laufen.

Performance und Ausführungspläne prüfen

Der Planer arbeitet anders als der von Oracle, und Optimizer-Hints gibt es nicht. Statt dessen justierst du work_mem, shared_buffers, effective_cache_size und die Statistikziele, liest Pläne mit EXPLAIN ANALYZE und beobachtest über pg_stat_statements, welche Abfragen wirklich teuer sind. Genau hier zahlt sich Tuning-Wissen aus, wie es der PostgreSQL Advanced-Training zu Performance-Tuning vermittelt.

Betrieb aufbauen, bevor du umschaltest

Backup mit pg_basebackup oder pgBackRest, Point-in-Time-Recovery, Streaming-Replikation, Monitoring und ein geübtes Restore-Verfahren gehören vor den Go-live. Der PostgreSQL Aufbaukurs zu Backup und Datenintegrität deckt diesen Teil ab, der PostgreSQL für Administratoren Grundkurs die Basis darunter.

Tutorial

Der Weg von der Bewertung bis zur Umschaltung

Zuerst misst du den Aufwand mit dem Bewertungsbericht von ora2pg, dann richtest du das Ziel ein und übernimmst Schema und Typen. Danach kommt der teure Teil mit PL/SQL, anschließend der Datentransfer mit echter Verifikation, die Prüfung der Ausführungspläne und zuletzt der Betrieb samt Rückweg.

01

Aufwand messen statt schätzen

ora2pg liefert dir vor der ersten Zeile Code eine Objektliste mit Schwierigkeitsbewertung. Das ist die einzige belastbare Grundlage für die Projektplanung.

Projekt anlegen und Bericht erzeugen
# Verzeichnisstruktur, mit der ora2pg selbst arbeitet
ora2pg --project_base /opt/migration --init_project kundendb

# Bewertungsbericht inklusive Aufwandsschätzung je Objekt
ora2pg -c /opt/migration/kundendb/config/ora2pg.conf \
       -t SHOW_REPORT --estimate_cost --dump_as_html \
       > /opt/migration/bericht.html

# Was steckt überhaupt im Schema?
ora2pg -c /opt/migration/kundendb/config/ora2pg.conf -t SHOW_TABLE
ora2pg -c /opt/migration/kundendb/config/ora2pg.conf -t SHOW_COLUMN

Der Bericht rechnet in Aufwandseinheiten, deren Standardwert bei fünf Minuten liegt und über COST_UNIT_VALUE anpassbar ist. Nimm die Zahl nicht als Wahrheit, sondern kalibriere sie: portiere drei mittelgroße Prozeduren wirklich und halte die gemessene Zeit gegen die Schätzung. Der Faktor, den du dabei bekommst, gilt danach für das ganze Projekt.

Was den Aufwand wirklich treibt

ObjektartTypischer Stolperstein
Tabellen und IndizesLäuft weitgehend automatisch, Prüfaufwand steckt in den Datentypen
ViewsMeist automatisch, außer bei CONNECT BY und Oracle-eigenen Funktionen
PL/SQL-PaketeHauptaufwand. Zustand in Paketvariablen hat in PostgreSQL kein Gegenstück
TriggerAndere Struktur: PostgreSQL braucht eine Funktion plus getrenntes CREATE TRIGGER
Jobs aus DBMS_SCHEDULERKein Gegenstück im Kern, wandert nach pg_cron oder auf systemd-Timer
SQL im AnwendungscodeTaucht im Bericht nicht auf und wird trotzdem der teuerste Posten
02

Zielsystem einrichten und Schema übernehmen

Die Version des Zielsystems entscheidest du bewusst, nicht die Distribution. Erst danach kommt das Schema.

PostgreSQL aus der Projektquelle installieren
# Debian/Ubuntu
sudo apt install -y postgresql-common
sudo /usr/share/postgresql-common/pgdg/apt.postgresql.org.sh

# RHEL/Rocky/Alma: erst die PGDG-Quelle einbinden, sonst gibt es die
# versionierten Paketnamen gar nicht
sudo dnf install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-9-x86_64/pgdg-redhat-repo-latest.noarch.rpm

# dann das Distributionsmodul abschalten, sonst gewinnt das alte Paket
sudo dnf -qy module disable postgresql
sudo dnf install -y postgresql17-server postgresql17-contrib
sudo /usr/pgsql-17/bin/postgresql-17-setup initdb
sudo systemctl enable --now postgresql-17

Der abgeschaltete Modulstrom auf RHEL-Systemen ist der Schritt, den fast alle vergessen. Ohne ihn installiert dnf weiter die ältere Version aus dem AppStream, und du wunderst dich über fehlende Funktionen. Unter Debian und Ubuntu landen die Cluster unter /etc/postgresql/ und werden mit pg_ctlcluster verwaltet, unter RHEL liegt das Datenverzeichnis unter /var/lib/pgsql/.

Schema in Einzelteilen exportieren
cd /opt/migration/kundendb
ora2pg -c config/ora2pg.conf -t TABLE    -o table.sql    -b schema/tables
ora2pg -c config/ora2pg.conf -t VIEW     -o view.sql     -b schema/views
ora2pg -c config/ora2pg.conf -t SEQUENCE -o sequence.sql -b schema/sequences
ora2pg -c config/ora2pg.conf -t TRIGGER  -o trigger.sql  -b schema/triggers

psql -d kundendb -v ON_ERROR_STOP=1 -f schema/tables/table.sql

Mit ON_ERROR_STOP=1 bricht psql beim ersten Fehler ab, statt hundert Folgefehler zu produzieren, in denen der eigentliche Fehler untergeht. Spiel Indizes und Constraints bewusst erst nach dem Datenimport ein, ora2pg legt sie dafür in eigene Dateien.

Typumsetzung mit Entscheidung

OraclePostgreSQLWorauf du achten musst
NUMBER ohne Skalabigint oder numericnumeric rechnet exakt und deutlich langsamer. Wo ein Ganzzahlbereich reicht, nimm bigint
NUMBER(p,s)numeric(p,s)Direkte Entsprechung, Nachkommastellen prüfen
VARCHAR2(n)varchar(n) oder texttext ist in PostgreSQL nicht langsamer als varchar
DATEtimestamp(0)Oracles DATE enthält immer eine Uhrzeit, der PostgreSQL-Typ date nicht
CLOBtextUnauffällig, aber Kodierung prüfen
BLOBbyteaAb Werten um ein Gigabyte brauchst du Large Objects statt bytea
RAW(16)uuidNur wenn dort wirklich UUIDs stehen, sonst bytea
03

PL/SQL nach PL/pgSQL portieren

Hier liegt der Aufwand. Die Syntax ist ähnlich genug, um zu täuschen, und unterschiedlich genug, um jede automatische Übersetzung an denselben Stellen scheitern zu lassen.

Konstrukte und ihr Gegenstück

OraclePostgreSQL
NVL, DECODECOALESCE, CASE, oder unverändert lassen mit der Erweiterung orafce
SYSDATECURRENT_TIMESTAMP, innerhalb einer Transaktion clock_timestamp()
ROWNUMLIMIT und OFFSET, bei Nummerierung row_number() OVER ()
CONNECT BY PRIORWITH RECURSIVE
FROM DUALEntfällt ersatzlos
Paketvariablen mit Zustand über Aufrufe hinwegKein Gegenstück, Umbau auf Parameter oder temporäre Tabelle
Autonome TransaktionenKein Gegenstück, Umweg über dblink
MERGESeit PostgreSQL 15 vorhanden, davor INSERT ... ON CONFLICT
Optimizer-Hints im KommentarWerden ignoriert. Steuerung läuft über Statistiken und Parameter
Oracle-Funktionen nachrüsten statt jede Zeile umschreiben
CREATE EXTENSION IF NOT EXISTS orafce;

-- Suchpfad so setzen, dass die Oracle-kompatiblen Varianten greifen
ALTER DATABASE kundendb SET search_path TO public, oracle, pg_catalog;

-- Danach funktionieren unter anderem diese Aufrufe unverändert weiter
SELECT nvl(rabatt, 0), to_char(sysdate, 'DD.MM.YYYY') FROM dual;

orafce bringt viele Funktionen, Pakete und den Ersatz für dual mit. Das spart dir tausende Änderungen im Anwendungscode und ist trotzdem eine Zwischenlösung: Neuer Code sollte die PostgreSQL-eigenen Funktionen verwenden, sonst schleppst du die Abhängigkeit auf Dauer mit.

Die offenen Stellen im Ausgabecode finden
# Was ora2pg nicht übersetzen konnte, steht als Kommentar im Ergebnis
grep -rniE 'not supported|unsupported|TODO|FIXME' \
     /opt/migration/kundendb/schema/functions/ \
     /opt/migration/kundendb/schema/procedures/ | wc -l

# Funktionen, die syntaktisch nicht durchlaufen, findest du beim Einspielen
psql -d kundendb -v ON_ERROR_STOP=0 -f schema/functions/functions.sql 2>&1 \
  | grep -E '^(FEHLER|ERROR)' | sort | uniq -c | sort -rn

Die zweite Liste ist deine Arbeitsvorrat-Liste, sortiert nach Häufigkeit. Meist stecken hinter hundert Fehlermeldungen fünf verschiedene Ursachen, und wenn du die fünf löst, verschwinden die hundert. Fang oben an, nicht bei der ersten Datei.

04

Daten laden und wirklich verifizieren

Der Ladevorgang ist Fleißarbeit. Die Verifikation danach entscheidet, ob du produktiv gehen kannst.

Parallel laden, Indizes danach
# -J liest parallel aus Oracle, -j schreibt parallel nach PostgreSQL
ora2pg -c config/ora2pg.conf -t COPY -J 4 -j 8

# Erst nach dem Laden: Indizes, Constraints und Fremdschlüssel
psql -d kundendb -v ON_ERROR_STOP=1 -f schema/tables/INDEXES_table.sql
psql -d kundendb -v ON_ERROR_STOP=1 -f schema/tables/CONSTRAINTS_table.sql
psql -d kundendb -v ON_ERROR_STOP=1 -f schema/tables/FKEYS_table.sql

# Sequenzen auf den Stand der geladenen Daten ziehen
psql -d kundendb -c "SELECT setval('buchungen_id_seq', (SELECT max(id) FROM buchungen));"

Indizes während des Ladens kosten ein Vielfaches der Zeit, weil jeder Datensatz zusätzlich in jeden Index geschrieben wird. Der letzte Befehl ist der Klassiker unter den vergessenen Schritten: ohne ihn vergibt die Sequenz nach dem Umschalten IDs, die es bereits gibt, und das Fachverfahren läuft mit Schlüsselverletzungen auf.

Verifikation, die mehr prüft als die Zeilenzahl
-- Summen und Extremwerte je Fachtabelle, auf beiden Seiten identisch abfragen
SELECT count(*), sum(betrag), min(buchung), max(buchung) FROM buchungen;

-- Inhaltliche Prüfsumme über die ganze Tabelle
SELECT md5(string_agg(t::text, '|' ORDER BY t.id)) FROM buchungen t;

-- Leerstrings, die in Oracle NULL waren
SELECT count(*) FROM kunden WHERE bemerkung = '';

Der reine Zeilenvergleich übersieht genau die Fehler, die weh tun: abgeschnittene Nachkommastellen durch ein zu enges numeric, um Stunden verschobene Zeitstempel durch die falsche Zeitzone und aus NULL gewordene Leerstrings. ora2pg kann den Abgleich mit -t TEST auch selbst fahren, das prüft aber Objekt- und Zeilenzahlen, nicht die Inhalte.

05

Ausführungspläne und Statistiken prüfen

Nach dem Import ist die Datenbank technisch fertig und fühlt sich trotzdem langsam an. Die Ursache ist fast immer dieselbe.

Statistiken erzeugen und teure Abfragen finden
VACUUM ANALYZE;   -- nach jedem Massenimport, nicht optional

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
-- braucht shared_preload_libraries = 'pg_stat_statements' und einen Neustart

SELECT calls,
       round(mean_exec_time::numeric, 1) AS ms_schnitt,
       left(query, 90) AS abfrage
  FROM pg_stat_statements
 ORDER BY total_exec_time DESC
 LIMIT 10;

EXPLAIN (ANALYZE, BUFFERS, SETTINGS)
SELECT * FROM buchungen b JOIN kunden k ON k.id = b.kunde_id
 WHERE b.buchung >= date_trunc('month', now());

Vergleiche in der Ausgabe von EXPLAIN (ANALYZE) immer die geschätzte mit der tatsächlichen Zeilenzahl. Weichen die beiden um Größenordnungen ab, hat der Planer keine brauchbaren Statistiken, und jede Optimierung an der Abfrage ist verschwendete Zeit.

Stellschrauben, die nach der Migration zuerst greifen

  • shared_buffers und effective_cache_size an den tatsächlichen Arbeitsspeicher anpassen, die Standardwerte sind für kleine Systeme gedacht
  • random_page_cost auf Flash-Speicher deutlich senken, sonst meidet der Planer Indexzugriffe ohne Grund
  • work_mem je Verbindung setzen, nicht global großzügig, sonst summiert es sich über die Verbindungen
  • Fremdschlüsselspalten indizieren, PostgreSQL legt dafür anders als für Primärschlüssel keinen Index automatisch an
  • auto_explain im Testbetrieb aktivieren, damit langsame Abfragen ihren Plan gleich mitliefern
06

Betrieb aufbauen, bevor du umschaltest

Eine migrierte Datenbank ohne Sicherungskonzept und Ausfallplan ist ein Risiko, kein Ergebnis. Diese Punkte gehören vor den Umschalttag.

Betriebsreife vor der Umschaltung

  • Sicherung mit Wiederherstellung testen, nicht nur einrichtenpgBackRest oder Barman geben dir mit WAL-Archiv eine Zeitpunktwiederherstellung. Eine Sicherung, die nie zurückgespielt wurde, ist eine Vermutung. Miss dabei die Dauer, das ist deine reale Wiederanlaufzeit.
  • Automatischen Failover einrichten statt HandbetriebStreaming-Replikation allein macht keinen Failover. Ohne automatische Führungswahl, etwa über Patroni, entscheidet nachts ein Mensch unter Druck, und zwei aktive Primaries richten mehr Schaden an als ein Ausfall.
  • Einen Verbindungspool vorschaltenPostgreSQL startet für jede Verbindung einen eigenen Prozess. Anwendungen, die aus der Oracle-Welt mit mehreren hundert offenen Verbindungen kommen, brauchen PgBouncer davor, sonst verbrennt der Server Arbeitsspeicher für Leerlauf.
  • Parallelbetrieb mit Lesevergleich fahrenSchick einen Teil der Leseabfragen zusätzlich an PostgreSQL, solange Oracle noch führend ist. Abweichungen findest du so ohne Risiko und an echten Daten statt an Testfällen.
  • Den Rückweg definieren und befristenSolange die Oracle-Instanz läuft und die Anwendung per Konfiguration umschaltbar ist, kostet ein Rückzug Minuten. Ist das Altsystem abgebaut, kostet er Wochen. Setz ein Datum, ab dem der Rückweg entfällt, sonst zahlst du die Lizenz noch Jahre parallel.
Wissen prüfen

Teste dich und finde deinen Weg

Bevor du einen Kurs buchst, lohnt sich eine ehrliche Standortbestimmung. Die Tests sind kostenlos und ohne Anmeldung.

Gut zu wissen

Häufige Fragen zu Migration von Oracle zu PostgreSQL

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt
Wie viel einer Oracle-Datenbank kann ora2pg automatisch migrieren?
Struktur und Daten übernimmt ora2pg in der Regel weitgehend automatisch, also Tabellen, Constraints, Indizes, Sequenzen und den Inhalt. Bei Views, Triggern und PL/SQL-Packages liefert das Werkzeug eine Übersetzung als Entwurf und eine Aufwandsschätzung, die du fachlich prüfen und meist nacharbeiten musst. Wie hoch der manuelle Anteil ausfällt, hängt fast ausschließlich davon ab, wie viel Geschäftslogik in der Datenbank liegt.
Welche Oracle-Funktionen haben in PostgreSQL kein direktes Gegenstück?
Am häufigsten stolpern Teams über Packages mit Sessionzustand, autonome Transaktionen, Optimizer-Hints, hierarchische Abfragen mit CONNECT BY, Advanced Queuing und Real Application Clusters. Für die meisten Punkte gibt es tragfähige Ersatzlösungen, etwa rekursive CTEs, dblink, Streaming-Replikation oder externe Queue-Systeme, aber es ist eine Design-Entscheidung und keine reine Syntaxübersetzung.
Wie stelle ich sicher, dass nach der Migration keine Daten fehlen?
Verlass dich nicht auf ein einzelnes Kriterium. Vergleiche Zeilenzahlen pro Tabelle, bilde Prüfsummen über fachliche Schlüssel und Beträge, prüfe Grenzfälle bei NULL und Leerstring, kontrolliere Zeitzonen sowie Zeichenkodierung und lass die Anwendung im Parallelbetrieb gegen beide Systeme lesen. Erst wenn diese Vergleiche über mehrere Durchläufe stabil sind, ist der Cutover vertretbar.
Ist PostgreSQL für unternehmenskritische Systeme mit Support verfügbar?
Ja, PostgreSQL selbst ist quelloffen und lizenzkostenfrei, kommerzieller Support ist über spezialisierte Anbieter und über die Enterprise-Distributionen erhältlich. Für den Vergleich der Gesamtkosten solltest du diesen Support, den Migrationsaufwand und den Schulungsbedarf deines Teams mit einrechnen, statt nur die eingesparten Lizenzgebühren gegenüberzustellen.
Lohnt sich der Umstieg auch von MySQL, MariaDB oder SQL Server?
Der methodische Ablauf ist derselbe, nur die Reibungspunkte verschieben sich. Bei MySQL und MariaDB geht es eher um Storage-Engines, laxe Typprüfung und abweichendes Verhalten bei Datumswerten, bei SQL Server um T-SQL, Identity-Spalten und die Sortierreihenfolge. Die Schritte Assessment, Schema, Logik, Datenabgleich und Betriebsaufbau gelten unverändert.

Zuletzt geprüft am 26. Juli 2026.

Das sagen Teilnehmer

Echte Stimmen aus unseren IT-Kursen

Sehr intensiver Lehrgang, hat mich für meine Arbeit ein gutes Stück voran gebracht.
Rückmeldung aus dem Kurs „Monitoring mit Prometheus und Grafana - Grundkurs“
Es war eine sehr gute Lernatmosphäre und der Trainer verstand sein Thema sehr gut.
Rückmeldung aus dem Kurs „SELinux Training: Grundlagen und Administration (SEL1)“
Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.

Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.

Nächster Schritt

Migration mit belastbarem PostgreSQL-Wissen angehen

Wenn dein Team den Umstieg selbst tragen soll, braucht es Sicherheit in Administration, Backup und Tuning. Bei cmt findest du dafür den PostgreSQL für Administratoren Grundkurs, den Aufbaukurs zu Backup und Datenintegrität sowie das Advanced-Training zum Performance-Tuning, wahlweise als Live-Online-Termin oder als Inhouse-Schulung auf eure Landschaft zugeschnitten. Sprich uns an, wenn du vorab klären willst, welcher Kurs zu eurem Migrationsstand passt.