Ratgeber & Vergleiche · Stand: 18. Oktober 2026

Change Data Capture: Änderungen erfassen und zuverlässig weiterverarbeiten

Change Data Capture (CDC) erfasst Änderungen an Quelldaten – etwa Insert, Update und Delete – und stellt sie nachgelagerten Systemen bereit. Damit daraus ein verlässlicher Zielbestand entsteht, müssen Erfassung, Quellposition, Anwendung im Ziel und Wiederanlauf zusammenpassen. Ein Connector, der Daten liefert, beantwortet noch nicht, ob das Ziel vollständig und korrekt aktualisiert wurde.

CDC kann beispielsweise Berichte, einen Suchindex oder einen zweiten Datenbestand mit Änderungen versorgen. Der Nutzen hängt davon ab, wie aktuell das Ergebnis sein muss und welche Fehlerfolgen akzeptabel sind. Der folgende Ablauf erklärt diese Entscheidung an einem ausdrücklich vereinfachten Modell.

Was CDC gegenüber einem Ladeprotokoll zeigt

Ein ETL-Protokoll kann festhalten: „Die Datei wurde um 02:00 Uhr geladen; der Lauf war erfolgreich.“ Daraus folgt nicht, welcher einzelne Vorgang angelegt, geändert oder gelöscht wurde. CDC bezieht sich auf diese Änderungen der Quelldaten. Microsoft beschreibt dafür ausdrücklich Insert, Update und Delete.

Ein Änderungsdatensatz kann etwa mitteilen: Der Vorgang A1 wurde von offen auf erledigt gesetzt. Der Laufstatus beschreibt dagegen den Verarbeitungsprozess. Beide Informationen sind für den Betrieb nützlich, beantworten aber unterschiedliche Fragen.

CDC ist dabei ein Erfassungsmechanismus. Es ersetzt weder die fachliche Aufbereitung noch das Modell eines Berichts oder die korrekte Schreiblogik eines Zielsystems.

Drei Wege, Änderungen zu erkennen

Die erreichbare Quelle setzt die erste Grenze: Ist ihr Transaktionslog zugänglich? Darf zusätzliche Datenbanklogik eingerichtet werden? Gibt es wenigstens eine verlässliche Änderungsmarke oder einen offiziellen Änderungsfeed?

Log-basierte Erfassung

Log-basierte CDC nutzt die Änderungsinformationen des Datenbanksystems. PostgreSQL gewinnt beim Logical Decoding aus dem Write-Ahead Log, kurz WAL, eine für Anwendungen nutzbare Darstellung von Änderungen. Der Debezium-PostgreSQL-Connector verarbeitet darüber die Änderungen von Transaktionen und führt quellbezogene Positionsinformationen mit.

So muss die Lösung nicht bei jedem Durchlauf erneut den gesamten Tabellenbestand nach Veränderungen durchsuchen. Das bedeutet jedoch keine Lastfreiheit. Datenbankversion, Logical-Decoding-Verfahren beziehungsweise Plugin, Konnektor, Konfiguration und Berechtigungen müssen zusammenpassen; auch der erste Bestandsabzug und die Aufbewahrung der Logs beanspruchen Ressourcen.

Ebenso wenig sind vollständige Vorherwerte selbstverständlich. Bei Debezium und PostgreSQL bestimmt unter anderem die Einstellung REPLICA IDENTITY, welche früheren Spaltenwerte für Updates und Deletes verfügbar sind. Prüfen Sie deshalb die konkrete Ereignissemantik, bevor Sie darauf eine Verarbeitung aufbauen.

Trigger-basierte Erfassung

Ein Trigger reagiert innerhalb der Datenbank auf festgelegte Schreiboperationen. Eine eigene Lösung kann damit Änderungsinformationen in zusätzliche Tabellen schreiben. Diese Logik wird Teil des zu betreibenden Schreibpfads: Sie benötigt Entwicklung, Tests, Bereitstellung und Wartung bei Schemaänderungen.

Beurteilen Sie deshalb auch fehlerhafte oder langsame Trigger und die Bereinigung ihrer Zusatztabellen. Microsoft nennt Trigger, Zeitstempelspalten und zusätzliche Tabellen als mögliche Bestandteile selbst entwickelter Verfahren und weist auf deren Implementierungs- und Betriebsaufwand hin. Ein allgemeiner Performance-Sieger lässt sich daraus nicht ableiten.

Abfragen, Zeitstempel und Änderungsfeeds

Ohne Logzugang kann ein regelmäßiger Abruf nach einem Änderungszeitpunkt oder einer geeigneten fortlaufenden Marke ausreichen. Dafür muss klar sein, wann die Marke gesetzt wird und welche Änderungen eine Abfrage erfasst. Überlappende Abrufbereiche, mehrere Änderungen mit gleicher Zeitmarke und noch laufende Transaktionen gehören zu den Prüffällen. „Alles nach der letzten Uhrzeit lesen“ ist allein noch kein belastbares Verfahren.

Physisch gelöschte Zeilen erscheinen in einer späteren Tabellenabfrage nicht mehr. Ohne Löschkennzeichnung, gesonderten Feed oder Bestandsvergleich lässt sich ihr Verschwinden damit nicht einfach als einzelnes Delete weitergeben.

Bei einer fremd betriebenen Anwendung oder einem SaaS-System kann der direkte Logzugriff ganz fehlen. Prüfen Sie dann angebotene APIs, Änderungsfeeds und deren Aufbewahrung oder einen vollständigen beziehungsweise inkrementellen Abgleich. Fehlende Rechte sind eine Architekturgrenze, die eine andere Methode verlangen kann.

Vom Startbestand zum Änderungsstrom

Ein leerer Zielbestand wird nicht vollständig, wenn er nur die Änderungen ab heute erhält. Zunächst braucht die Lösung einen Startbestand, häufig als Snapshot bezeichnet. Danach muss der Änderungsstrom ohne unerkannte Lücke anschließen.

Beim Debezium-PostgreSQL-Connector verbindet das dokumentierte Snapshot-Verfahren den Tabellenabzug mit einer gelesenen Logposition. Nach dem Snapshot setzt der Strom an der zugehörigen Position an. Das gewählte Verfahren und seine Konfiguration sind entscheidend; ein beliebiger Export mit einem später gestarteten Connector stellt diesen Zusammenhang nicht automatisch her.

Die Loghistorie ist außerdem nicht unbegrenzt verfügbar. Halten Sie fest, was bei einem abgebrochenen ersten Abzug geschieht und wie Daten behandelt werden, die bereits währenddessen geändert wurden. Prüfen Sie den Übergang mit echten Änderungsfällen, statt nur die Anzahl exportierter Zeilen zu vergleichen.

Capture, Transport und Anwenden trennen

Für den folgenden Entwurf lassen sich drei Verantwortungen unterscheiden:

Vereinbaren Sie dafür einen Ereignisvertrag: Welche Quelle und Tabelle sind gemeint? Welcher Schlüssel identifiziert die Zeile? Welche Operation liegt vor? Welche Werte und welche Quellposition werden mitgegeben? Die Positionsmarke ist konnektorspezifisch; beim PostgreSQL-Connector verwendet Debezium eine Log Sequence Number, kurz LSN.

Eine Reihenfolgezusage gilt nur für den tatsächlich definierten Strom beziehungsweise die jeweilige Partition. Aus einer Quellposition ergibt sich keine beliebige globale Ordnung über mehrere Datenbanken. Ebenso ist „Zeile aktualisiert“ noch kein fachliches Ereignis wie „Kunde hat Vertrag freigegeben“: Diese Bedeutung muss die Anwendung gegebenenfalls gesondert ableiten.

Insert, Update und Delete an einem Modell nachvollziehen

Das folgende fiktive Modell nimmt einen einzelnen geordneten Änderungsstrom, stabile Vorgangsschlüssel und für Updates ausreichende neue Statuswerte an. 100 bis 104 sind nur anschauliche Positionsmarken, keine echte LSN und keine produktive Konfiguration. Der Snapshot enthält bei Position 100 den Vorgang A1: offen.

Für die Zielverarbeitung führen wir zusätzlich die zuletzt angewendete Position je Schlüssel. Diese Information bleibt im Modell auch nach einer Löschung erhalten. Der bestätigte Gesamtfortschritt beschreibt dagegen den bis dahin vollständig erledigten Teil des Stroms.

Das Beispiel zeigt zwei Aufgaben: Wiederholungen dürfen keine zusätzliche Wirkung erzeugen; ältere Änderungen dürfen einen neueren Stand nicht überschreiben. Nach einem Delete reicht es dafür in diesem Modell nicht, nur die sichtbare Zeile zu entfernen. Sonst könnte das verspätete Insert 101 den gelöschten Vorgang wiederherstellen.

„Upsert“ bezeichnet konzeptionell das Einfügen oder Aktualisieren anhand eines Schlüssels. Für einen vollständigen CDC-Verbraucher kommen Löschungen, Reihenfolge und Wiederholungen hinzu. Ein einfaches MERGE ohne diese Regeln ist deshalb noch kein Beleg für korrekte Verarbeitung. Bei parallel ausgeführten Schritten muss der Entwurf außerdem verhindern, dass eine später fertiggestellte Position einen noch offenen Vorgänger verdeckt. Das Modell ist eine Entwurfshilfe, kein ausführbares SQL-Rezept.

Die Grafik ordnet Startbestand, Änderungen, Anwendung und bestätigten Fortschritt in denselben Ablauf ein.

Ein Abbruch zwischen Schreiben und Bestätigen

Angenommen, das Ziel hat Delete 103 bereits erfolgreich gespeichert. Die Bestätigung des Gesamtfortschritts steht aber noch auf 102, als der Prozess abstürzt. Beim Neustart kann 103 erneut eintreffen. Genau deshalb muss die Zielverarbeitung Wiederholungen vertragen. Debezium beschreibt solche doppelten Lieferungen nach einem Crash ausdrücklich.

Die Bestätigungsregel im Modell lautet: Erst nach erfolgreichem Anwenden darf der zugehörige Fortschritt als verarbeitet gelten. Wie Zieländerung und Fortschrittsinformation zuverlässig zusammengeführt werden, ist eine konkrete Implementierungsaufgabe. Ein Offset des Capture-Connectors und der Fortschritt eines nachgelagerten Verbrauchers können dabei verschiedene Zustände beschreiben. Lesen oder Transportieren allein beweist keinen erfolgreichen Ziel-Commit.

Sind benötigte Logabschnitte nach einer langen Pause nicht mehr verfügbar, darf die Verarbeitung keine Kontinuität vortäuschen. Dann braucht es ein geprüftes Verfahren zum Neuaufbau oder erneuten Abgleich des betroffenen Bestands, einschließlich eines neuen konsistenten Übergangs zum Strom.

Welche Aufgaben von CDC profitieren

Weniger Vollabzüge können ein Nutzen sein, wenn der Anwendungsfall dazu passt. Vergleichen Sie aber die bisherige Last mit Capture, Transport und Zielverarbeitung. CDC ist kein allgemeiner Beleg für geringere Kosten oder eine bestimmte Aktualität.

CDC, Replikation und Historie unterscheiden

CDC erfasst Änderungen. Replikation verfolgt die weitergehende Aufgabe, einen Zielbestand über eine gewählte Technik zu synchronisieren. Dazu gehören auch der Startbestand, die Schemafähigkeit, korrektes Anwenden und die Überprüfung des Ergebnisses. Für Migration oder Parallelbetrieb muss ausdrücklich feststehen, welches System Änderungen führen darf. Zwei beschreibbare Systeme werden durch einen einseitigen Änderungsstrom nicht automatisch widerspruchsfrei.

Eine fachliche Historisierung im Warehouse ist wiederum eine eigene Entscheidung: Welche Zustände sollen wie lange erhalten bleiben, und welcher fachliche Zeitbezug gilt? Slowly Changing Dimensions, kurz SCD, können solche Änderungen modellieren; Typ 2 erhält zeitbezogene Versionen. Der Capture-Feed legt dieses Modell nicht fest.

Produktspezifische Begriffe verlangen ebenfalls Genauigkeit: Bei SQL Server meldet Change Tracking, welche Zeilen sich geändert haben; die aktuellen Werte liest die Anwendung aus den Tabellen. CDC erfasst dort zusätzlich die geänderten Daten. Die Microsoft-Gegenüberstellung ist keine universelle Definition jeder gleich benannten Herstellerfunktion.

Ein aufbewahrter Änderungsverlauf kann Nachvollziehbarkeit unterstützen. Für einen Auditbedarf sind Aufbewahrung, Zugriff und Integrität gesondert zu planen; CDC allein garantiert weder eine unveränderliche Historie noch Compliance.

CDC ist eine Quelle für ETL und Streaming

Ein CDC-Feed kann eine ETL-/ELT-Pipeline versorgen oder Teil einer Streamingverarbeitung sein. Zwischen Erfassung und Anwendung dürfen Puffer und Batchschritte liegen. Ein regelmäßiger Verbraucher macht die Quelländerungen nicht zu gewöhnlichen Ladeprotokollen; eine laufende Verbindung macht den fertigen Bericht noch nicht unmittelbar aktuell.

Für KI gilt dieselbe Grenze: Ein geänderter Referenzdatensatz kann einen Aktualisierungsschritt anstoßen. Die fachliche Eignung der Daten, die Modelllogik oder ein Suchindex müssen dennoch gesondert gepflegt und geprüft werden. Aus CDC allein folgt kein korrektes Modell und kein stets aktuelles RAG-Ergebnis.

Den Betrieb um den Änderungsstrom aufbauen

Die erforderlichen Steuerungsaufgaben können in einer Plattform, einer Anwendung oder einer eigenen Orchestrierung liegen. Entscheidend ist ihre Zuordnung. Der Capture-Prozess muss laufen; Zielverarbeitung, Anreicherung, Qualitätsprüfungen und Löschbehandlung müssen koordiniert werden. Für einen Fehler braucht es einen beobachtbaren Zustand und eine verantwortliche nächste Aktion.

Im Modell wäre eine fehlgeschlagene Anwendung von 103 sichtbar zu halten. Der Betrieb meldet den offenen Fehler, bestätigt den Fortschritt nicht darüber hinaus und stößt nach der Korrektur einen verträglichen Wiederanlauf an. Ein Backfill – das Nachladen eines fehlenden oder neu benötigten Bestands – benötigt ebenfalls einen definierten Zeitraum und eine Abstimmung mit bereits laufenden Änderungen.

Beobachten Sie sowohl den Betriebszustand als auch das Datenresultat: Ein grüner Prozessstatus erkennt nicht jeden fehlenden oder falsch gelöschten Vorgang. Geplante Quell-Ziel-Abgleiche ergänzen deshalb technische Alarme.

Endgültige Aktualität statt „Echtzeit“ messen

Trennen Sie die Verzögerung der Erfassung, die Zeit im Puffer, den Start der Verarbeitung und die Dauer des Apply-Schritts. Der fachliche Rückstand reicht bis zum tatsächlich verwendbaren Ergebnis. Er lässt sich beispielsweise anhand einer bekannten Quelländerung und ihrer Sichtbarkeit im geprüften Ziel messen.

Ob jede Änderung eine eigene Ausführung startet oder mehrere Änderungen gesammelt werden, hängt von Aktualitätsbedarf, Durchsatz und Aufwand ab. Viele kleine Starts können andere Kosten und Betriebsgrenzen haben als ein gebündelter Lauf. Legen Sie einen tolerierten Rückstand und eine Reaktion bei Überschreitung fest, statt aus dem Begriff CDC feste Millisekunden abzuleiten.

Log-Retention, Quelllast und Rechte überwachen

Bei PostgreSQL können Replikationsslots benötigte WAL-Abschnitte und Kataloginformationen zurückhalten, auch wenn kein Verbraucher verbunden ist. Dadurch wird Speicher belegt. Die PostgreSQL-Dokumentation warnt ausdrücklich davor, nicht mehr benötigte Slots unbeachtet zu lassen.

Überwachen Sie deshalb getrennt die Last des Snapshots, den Rückstand der Verarbeitung und die zurückgehaltene Logmenge. Für wachsenden Rückstand braucht es eine festgelegte Reaktion: Ursache prüfen, verfügbare Aufbewahrung bewerten und gegebenenfalls den kontrollierten Neuaufbau vorbereiten. Einen noch benötigten Slot nur zur Speicherentlastung zu entfernen, kann den vorgesehenen Fortsetzungsweg zerstören.

Der Debezium-PostgreSQL-Connector benötigt passende Datenbankrechte. Seine Dokumentation empfiehlt einen eigenen Replikationsnutzer mit den erforderlichen Rechten statt unnötig weitreichender Superuser-Berechtigungen. Prüfen Sie außerdem, welche sensiblen Werte in den Änderungsdatensätzen landen und wer sie lesen darf. Änderungen von Schema und Schlüsseln sowie ein Wiederanlauf nach längerer Pause gehören zu den Betriebstests.

Werkzeuge anhand ihrer Semantik auswählen

Fordern Sie für die konkrete Quell- und Zielkombination nachvollziehbare Antworten an:

• Unterstützt der Connector die vorhandene Datenbankversion und die tatsächlich verfügbaren Rechte?
• Wie funktionieren Snapshot, Übergang und Wiederaufnahme? Welche Änderungen und Vorherwerte stehen zur Verfügung?
• Wie werden Deletes, Schlüsselwechsel, Schemaänderungen und Transaktionsgrenzen behandelt?
• Welche Positionen werden wo dauerhaft gespeichert, und was passiert nach einem Abbruch?
• Lassen sich Wiederholungen, Neuaufbau und Bestandsabgleich im vorgesehenen Betrieb durchführen?

Prüfen Sie darüber hinaus Teamfähigkeiten, verwalteten oder eigenen Betrieb und die Kostenstruktur. Capture-Verbrauch, Transport, Aufbewahrung und Zielverarbeitung können verschiedene Kostentreiber sein. Eine Aussage zu gespeicherten Transaktionsbatches oder Historie ist erst nützlich, wenn Umfang, Wiederherstellung und Grenzen für Ihren Fall klar sind.

Kafka ist keine Voraussetzung des Prinzips

CDC setzt keinen Kafka-Cluster voraus. Als konkrete Alternative kann die Debezium Engine Konnektoren in eine Anwendung einbetten und Änderungen direkt an diese liefern, statt sie in einem externen Kafka-Cluster abzulegen.

Dadurch entfallen die Aufgaben nicht: Die Anwendung braucht eine geeignete Laufzeit, dauerhafte Offsetablage und Fehlerbehandlung. Auch die Engine-Dokumentation beschreibt mögliche Wiederholungen nach einem Crash. Wählen Sie Transport und Betriebsmodell danach, welche Verbraucher, Pufferung und Wiederanlaufanforderungen Sie tatsächlich haben.

Wann ein einfacher Abgleich genügt

Ein kleiner Bestand, der nur gelegentlich für einen Tagesbericht gebraucht wird, kann mit einem nachvollziehbaren Vollabgleich auskommen. Ein verlässliches Änderungsmerkmal kann einen inkrementellen Lauf ermöglichen. Vergleichen Sie Änderungsmenge, erlaubte Quelllast, benötigte Aktualität und Löschsemantik mit dem zusätzlichen Betrieb eines CDC-Stroms.

Fehlen Logrechte oder ein geeigneter Feed, ist das früh zu berücksichtigen. Eine aufwendige Konstruktion liefert keinen Nutzen, wenn der Verbraucher die Aktualität nicht benötigt oder niemand die Fehlerfälle übernimmt. Zulässiger Datenumfang und Verantwortung bleiben auch bei einem langsameren Abgleich Teil der Entscheidung.

Ein CDC-Vorhaben konkret abnehmen

Verwenden Sie für den ersten Durchlauf einen bekannten Startbestand und protokollieren Sie erwartete Zielzustände. Der folgende eigene Prüfkatalog ist ein Ausgangspunkt für die Abnahme, kein behaupteter Produktnachweis:

Legen Sie vor dem produktiven Einsatz außerdem Alarme, Verantwortliche und die Entscheidung über einen Neuaufbau fest. Wenn Sie Quelle, Zielverarbeitung und Wiederanlauf gemeinsam auslegen möchten, ist Cloud Data & Intelligence von eBiz ein passender Anschluss. Ein geeigneter Ausgangspunkt ist die Frage, welcher Zielzustand nach einem konkreten Fehler nachweisbar wiederhergestellt werden muss.