Welche Optionen gibt es um Datenbankänderungen zwischen mehreren Datenbankinstanzen zu übertragen

Hallo zusammen,

ich habe bisher keine Erfahrung mit PostgreSQL und überlege welche technischen Möglichkeiten PostgreSQL bietet um mit folgendem Problem umzugehen:

Problem/Anforderung:
Es gibt 2 (oder mehrere) Datenbank-Instanzen - DEV (für die Entwicklung) und PROD (das Produktivsystem). DDL-Änderungen die auf der DEV durchgeführt werden, sollen später auf die PROD überführt werden.

Mir fallen 3 Optionen ein von denen ich nicht sicher bin ob alle 3 technisch umsetzbar sind:

Option 1: Änderungen manuell tracken
Alle DDL-Änderungen werden vor oder nach der Ausführung auf der DEV als Skript in einer Datei gespeichert. Dieses Skript kann dann beim Rollout auf der PROD ausgeführt werden. Das ist sicherlich die einfachste Möglichkeit - aber auch die fehleranfälligste. Insb. bei mehreren Entwicklern / vielen Datenbankänderungen.

Option 2: Diff der Datenbank vor dem Rollout
Vor dem Rollout wird ein Diff der 2 Datenbankinstanzen erstellt und die Unterschiede werden übertragen. Für MSSQL-Datenbanken gibt es die Möglichkeit sich für 2 Datenbankinstanzen automatisch ein Skript mit den Unterschieden erzeugen zu lassen - gibt es soetwas auch für postgreSQL?

Option 3: DDL-Logger
Alle DDL-Änderungen werden in einer Tabelle geloggt. Die geloggten Änderungen könnten dann entweder per Prozedur oder einem Tool auf eine andere Datenbank übertragen werden. Die Option hätte zusätzlich den Vorteil, dass eine Historie der Datenbankentwicklung entstände. Ich weiß, dass das loggen von DDL-Befehlen zumindest in MSSQL und Oracle möglich ist - Wird das auch für PostgreSQL unterstützt?

Den Anwendungsfall hat jeder der meit mehreren “Stages” arbeitet. Daher würde mich interessieren wie Ihr die Änderungen übertraget. Verwendet Ihr eine der 3 genannten Optionen oder gibt es vielleicht noch andere Möglichkeiten? Könnt Ihr irgendwelche Tools / Komponenten empfehlen die einem bei den Problem unterstützen?

Danke und Gruß

Option 1) ist die einzige die wirklich funktioniert.

Schema Migrationen dürfen ausschliesslich über Skripte erfolgen (ein manuelles ALTER TABLE is verboten). Diese Skripte gehören in die Versionskontrolle. Es gibt mehrere Tools die das Verwalten und Ausführen solcher Skripte vereinfachen. Wir verwenden seit Jahren schon Liquibase und sind sehr zufrieden damit. Es gibt aber auch andere Tools dafür (z.B. Flyway). Wenn man die Skripte über Continous Integration jede Nacht vor den Integration Tests laufen lässt kann man sich ziemlich sicher sein, dass auch alle Skripte vorhanden sind.

Option 2) funktioniert nicht - mit keinem DBMS. Ganz einfaches Beispiel: eine Spalte oder Tabelle wird umbenannt - woher will das Diff das wissen? Ein Diff wird dann ein DROP TABLE für den alten Namen generieren und ein CREATE TABLE für den neuen.

Danke für die schnelle Antwort!

Der Prozess scheint auf dem ersten Blick recht vielversprechend zu sein. Wie du schon sagst muss man sich damit abfinde keine Änderungen mehr direkt an der Datenbank vorzunehmen - das ist vermutlich Gewöhnungssache. Ich werde es mal ausprobieren.

Du hast recht, Option 2 würde beim Rename noch manuelle Nachbearbeitung des generierten Skripts benötigen. Die Option wäre also nicht wirklich praktikabel.