Verknüpfen Sie eine Datenbank mit einem Schema, und Entity Enricher pflegt Ihre angereicherten Entitäten als relationale Tabellen, die Ihnen gehören: eine echte company-Tabelle mit einer revenue-Spalte — keine Exportdatei. Laden Sie einmal einen sofort einsatzbereiten SQL-Snapshot herunter und halten Sie Ihre Datenbank anschließend mit einem inkrementellen Delta-Feed aus idempotenten Upserts konvergent.
Einmal speichern, bei Bedarf projizieren. Anreicherungen schreiben den aktuellen Entitätszustand in die Entitätsebene; jede verknüpfte Datenbank ist eine Projektion dieses Zustands, ausgeliefert als einmaliger Snapshot plus einem Delta-Feed, den Sie bestätigen. Das Bearbeiten eines Schemas kostet eine Neuprojektion, niemals eine Datenmigration.
database_sync: false); Anreicherungen anderer Nutzer werden weiterhin normal geroutet..sql-Snapshot (Tabellen + Daten) herunter und wenden Sie ihn auf Ihr PostgreSQL an. Das DDL enthält Join-Indizes und Fremdschlüssel (Kind- und Verknüpfungszeilen werden kaskadierend gelöscht, wenn eine Entität gelöscht wird). Der Datei-Header verrät Ihnen, ab welchem Delta-Cursor Sie fortsetzen müssen.Jeder Entitätstyp besitzt einen Datenbankschlüssel — die Spaltengruppe, die Ihre Tabellen als eindeutigen Index und als Konfliktziel beim Upsert verwenden. Wenn Sie eine Datenbank verknüpfen, schlägt ein KI-Klassifizierungsdurchlauf das gesamte Datenbankmodell (Schlüssel, Spaltentypen, Indizes, Eigentümerschaft) zur Prüfung vor und greift andernfalls auf eine einfache Rangfolge zurück: die semantische ID des Objekts, sofern vorhanden, sonst ein Id-artiges Feld (id, product_id, …), sonst die natürlichen Schlüssel des Objekts. In Ihren Tabellen erscheint eine semantische ID als Spalte semantic_id — der Name id bleibt für Ihre eigene Verwendung frei. Sie können sie jederzeit im Tab „Modell“ der Datenbank ändern — nach der Veröffentlichung ist das eine migrationsrelevante Änderung: Laden Sie den Snapshot anschließend erneut herunter. Nichts gelangt in Ihre Datenbank, bevor das Schema in diesem Tab veröffentlicht wurde (durch das bloße Verknüpfen werden weder Tabellen noch Zeilen übertragen).
Ein Datenbankschlüssel ist niemals nullbar. Ein Null-Wert entspricht keiner Zeile, sodass die Entität – statt aktualisiert zu werden – bei jeder Anreicherung als neues Duplikat eingefügt würde. Deshalb wird eine Anreicherung, deren Schlüssel leer zurückkommt, abgelehnt statt gespeichert. Der Editor hält die beiden Kennzeichen getrennt, und ein Schema, das beide setzt, wird beim Speichern oder beim Verknüpfen einer Datenbank abgelehnt, wobei die zwei Möglichkeiten zur Behebung genannt werden: die Eigenschaft immer vorhanden machen oder eine andere Eigenschaft als Schlüssel des Typs verwenden.
Wenn ein Datenbankschlüssel ein angereichertes Textfeld statt einer semantischen ID ist, entspricht der gespeicherte Wert der Antwort des Modells – nicht dem von Ihnen gesendeten Text. Wenn Sie ein Unternehmen in Ihrer Anfrage als Embraer bezeichnen, legt das dieses Feld nicht fest: Die Anreicherung kann Embraer S.A. antworten – eine korrigierte Schreibweise, ein ausgeschriebener Rechtsformzusatz, ein weggelassener Unterscheidungszusatz – und genau das bildet den Schlüssel der Zeile. Eine Suche nach dem von Ihnen gesendeten Wert kann die Zeile daher verfehlen (verwenden Sie die entity_keys, die mit jeder gespeicherten Anreicherung zurückgegeben werden), und ein späterer Lauf mit anderer Formulierung ergibt einen anderen Schlüssel – er fügt eine zweite Zeile ein, statt Ihre zu aktualisieren. Das ist bei jedem Schlüssel aus angereichertem Text zu erwarten. Abhilfe schafft eine semantische ID für diesen Typ: Varianten eines Namens werden zu einer einzigen stabilen Identität aufgelöst, sodass die Zeile erhalten bleibt, wie das Modell sie auch schreibt. Aktivieren Sie sie bei der Schema-Generierung – später hinzuzufügen bedeutet, jedes Objekt zu bearbeiten.
In Arrays verschachtelte Objekte werden zu eigenen Tabellen mit Verknüpfungszeilen, die die Reihenfolge bewahren; Wertobjekte ohne Identität bleiben in die Spalten ihres übergeordneten Objekts eingebettet. Eigenschaftsnamen werden wörtlich (in Anführungszeichen) übernommen – Ihre Spaltennamen sind die Eigenschaftsnamen Ihres Schemas, nur dort gekürzt, wo ein verschachtelter Pfad über das hinausginge, was PostgreSQL benennen kann.
Die Projektion ist deterministisch – dasselbe Schema wird immer auf dieselben Tabellen und Spalten abgebildet. Eigenschaftsnamen werden wortgetreu zu Spaltennamen (in Anführungszeichen); Typnamen werden per Snake-Case zu Tabellennamen (VideoGame → video_game). Die einzige Ausnahme ist die Länge: PostgreSQL kann keinen Bezeichner über 63 Byte aufnehmen, daher kürzt ein tief verschachtelter Pfad seine übergeordneten Objekte, damit er passt (morphological_description_ → morpdesc_) – derselbe Präfix für jede Spalte dieses Objekts, im Model-Tab vor dem Verknüpfen angezeigt und bearbeitbar. Eine Eigenschaft kann ihren Präfix auch ganz weglassen, um zu einer Spalte zu passen, die Ihre Datenbank bereits hat (product_identifiers.stock_keeping_unit → sku) – der Verknüpfungsschalter neben dem Namen im Model-Tab. Jede Tabelle trägt eine _sync_revision-Spalte, die dazu dient, Replays konvergent zu halten.
| In Ihrem Schema | In Ihrer Datenbank |
|---|---|
| Objekt mit Identität (semantische ID oder Schlüssel) | Eine eigene Tabelle; Datenbankschlüssel werden zum eindeutigen Index & Upsert-Ziel |
| Skalarfeld (String, Zahl, Boolean) | Eine typisierte Spalte (TEXT, BIGINT, NUMERIC, BOOLEAN) |
| Geschlossene Menge (ein Feld, das auf eine Werteliste beschränkt ist) | Eine einfache TEXT-Spalte — kein CHECK, kein Datenbank-Enum-Typ. Die Liste wird erzwungen, wenn die KI antwortet; das spätere Hinzufügen eines Werts migriert Ihre Datenbank daher nie. Fügen Sie bei Bedarf eine eigene Einschränkung hinzu — der Database Sync rührt sie nie an |
| Nullable- oder Non-Nullable-Feld | Ein nicht-nullbares Feld wird standardmäßig zu einer NOT NULL-Spalte, gekoppelt an das Qualitätsgate unten – beim strengsten Gate erhalten auch erforderliche Referenzen NOT NULL-Fremdschlüssel; schalten Sie die Durchsetzung ab – bei der Registrierung oder später: eine Änderung nach dem ersten Sync wird als abgesicherte Migration im Feed ausgeliefert –, damit alle Spalten nullbar bleiben und allein das Gate die Vollständigkeit durchsetzt |
| Mehrsprachiges Feld | Eine JSONB-Spalte, die alle Sprachen enthält |
| Eingebettetes Wertobjekt (keine Identität) | In präfixierte Spalten aufgeschlüsselt (dimensions_width) |
| Array von Wertobjekten | Eine untergeordnete Tabelle mit dem übergeordneten Schlüssel, geordnet, mit Kaskadierung beim Löschen |
Array von Entitäten / $ref-Beziehung | Eine Verknüpfungstabelle, die Quell- und Zielzeilen verbindet, unter Beibehaltung der Reihenfolge |
Schlüsselfeld (identifying) | Ein Sekundärindex für schnelle Abfragen |
| Abfrageförmiger Index (geordnete Feldliste) | Ein mehrspaltiger Index pro deklarierter Struktur, geordnet wie die Listenansicht-Abfrage, die er bedient — Facetten und geschlossene Wertemengen zuerst, die Sortier- oder Bereichsspalte zuletzt, mehrsprachige Felder eingeschlossen (eine solche Struktur wird einmal pro Sprache ausgeliefert, die Ihre Datenbank erhalten hat); vom Klassifizierungsdurchlauf mit Begründung vorgeschlagen, im Tab „Modell“ kuratiert, mehrere pro Entität |
| Suchfeld (Indexabsicht) | Ein Trigramm-Index (pg_trgm) auf Text, den Ihre Suchfelder nach Fragmenten durchsuchen — pro Sprache und ohne Obergrenze auf mehrsprachigen Spalten; niemals auf einem Dropdown-Wert, der stattdessen in einen abfrageförmigen Index gehört (mehrsprachige eingeschlossen — ein solcher Index wird einmal pro Sprache ausgeliefert, die Ihre Datenbank erhalten hat); auf Replikaten ohne die Erweiterung wird er übersprungen (ohne Wirkung), bis ein Datenbankeigentümer sie installiert |
| Koordinatenpaar (Breitengrad + Längengrad) | Ein räumlicher Index über das Paar (natives PostgreSQL GiST, ohne Erweiterung) — Abfragen zu Umkreis, nächsten Nachbarn und Kartenausschnitt |
| Intervallpaar (Start- + Endgrenze) | Ein Bereichsindex über das Paar — Abfragen zu Überschneidungen und dazu, „welcher Wert an diesem Datum galt“ |
Eine Datenbank kann mehr als ein Schema synchronisieren. Entitätstypen mit demselben Namen über die verknüpften Schemas hinweg landen in der selben Tabelle, zusammengeführt anhand ihres Datenbankschlüssels — die Anreicherungen jedes Schemas aktualisieren nur seine eigenen Spalten, sodass ein Unternehmen, das von zwei Schemas angereichert wird, zu einer Zeile mit beiden Spaltensätzen wird. Typen, die nur in einem Schema vorkommen, fügen einfach ihre eigenen Tabellen hinzu, geliefert über ein automatisches Migrations-Delta im Feed — kein erneuter Download nötig.
Wenn Sie ein Schema verknüpfen, zeigt ein Vergleichsschritt genau, welche Tabellen zusammengeführt werden (mit ihren Schlüsseln und hinzugefügten Spalten) und welche neu sind; ein Schema, das sich eine Tabelle teilt, übernimmt die vorhandenen Datenbankschlüssel dieser Tabelle, die Ihnen zur Prüfung angezeigt werden. Wenn die Schemas nichts gemeinsam haben, schlägt der Ablauf stattdessen eine dedizierte Datenbank vor. Das Trennen eines Schemas berührt Ihre Datenbank nie — die synchronisierten Tabellen bleiben erhalten.
Wenn Sie die Verknüpfung eines Schemas aufheben oder einen Sync löschen, bleiben auf unserer Seite zwei Dinge zurück: der gespeicherte Entitätsstatus, in den nichts mehr schreibt, und die Datenbankeigenschaften, die das Schema mitführt (Datenbankschlüssel, Spaltentypen, Indizes, Eigentümerschaft). Beide Bestätigungen bieten an, sie zu entfernen, und zwar nur für Schemas, die mit gar keiner Datenbank zurückbleiben — ein Schema, das anderswo noch synchronisiert wird, behält alles. Das Schema selbst, seine Anreicherungsdatensätze und seine Kosten sind nie betroffen.
Ein verknüpftes Schema hat einen veröffentlichten Vertrag: die Version, die Ihre Anreicherungen und Ihre Datenbank tatsächlich verwenden. Das Bearbeiten des Schemas betrifft nur eine Arbeitskopie – Formulierungsänderungen werden automatisch übernommen, während strukturelle Änderungen (neue Felder, Typ- oder Schlüsseländerungen) warten, bis Sie auf Veröffentlichen klicken. Beim Veröffentlichen wird die genaue Auswirkung als Vorschau angezeigt und die passende Migration in den Delta-Feed eingespeist: neue Spalten kommen als ALTER TABLE-Deltas an, und umfangreichere Änderungen (ein neuer Datenbankschlüssel, eine Typänderung) laufen als abgesicherte Migrationen gegen Ihre eigene Datenbank – falls Daten sie blockieren (ein fehlender oder doppelter Schlüsselwert), pausiert der Feed mit dem genauen Problem und versucht es automatisch erneut, sobald Sie es beheben.
Das Veröffentlichen erfolgt im Tab Model der Datenbank (der Workflow Editor zeigt ein Banner, das darauf verweist, solange das Schema verknüpft ist). Bevor Sie veröffentlichen, werden beide Seiten angezeigt: der Vertrag, auf dem Ihre Datenbank heute basiert, und ein Diff aller Änderungen, die Ihre Arbeitskopie vornehmen würde. Eine Änderung überzeugt Sie nicht? Auf veröffentlichte Version zurücksetzen stellt den Vertrag wieder her – umkehrbar, und der beiseitegelegte Entwurf bleibt 24 Stunden lang wiederherstellbar.
Das erneute Verknüpfen eines Schemas, das im nicht verknüpften Zustand bearbeitet wurde, funktioniert genauso: Die Synchronisierung merkt sich, was Ihre Datenbank bereits hat, und sendet nur die Differenz sowie eine Snapshot-Aktualisierung für die zwischenzeitlich geschriebenen Zeilen. Niemals ein manuelles DROP.
Dieselbe Zusage gilt für unsere eigenen Upgrades. Wenn ein neues Release verbessert, wie Schemas auf Tabellen abgebildet werden, wird Ihre Synchronisierung für Sie migriert – additive Änderungen erreichen den Feed von selbst. Wenn ein Upgrade Tabellen umformen würde, die Sie bereits enthalten, rühren wir Ihre Daten niemals unangekündigt an: Die Zustellung pausiert und Ihre Database-Sync-Seite bittet Sie, es anzuwenden, wobei zuerst genau angezeigt wird, was sich ändert.
Auch mehrsprachige enrichment wird hier erstklassig behandelt: Lokalisierte Werte kommen als JSONB-Spalten an, die jede Sprache des enrichment enthalten — {"en": "Headache", "fr": "Céphalée"} —, sodass eine einzige Datenbank alle Ihre Sprachräume auf einmal bedient. Wählen Sie eine Sprache direkt in Ihren Abfragen (name->>'fr'), und die JSON-Delta-Payloads enthalten dieselben nach Sprache verschlüsselten Objekte.
Jede Datenbank beantwortet bei der Registrierung eine Frage: Was wird geschrieben, wenn eine Anreicherung mit Lücken zurückkommt – also mit nicht gefüllten, nicht-nullbaren Feldern? Die drei Antworten bilden eine Leiter. Nichts: Eine einzige Lücke irgendwo, auch innerhalb eines verschachtelten Objekts, und die Entität wird abgelehnt. Die Entität, ohne ihre unvollständigen Kindobjekte (Standard): Die eigene Zeile der Entität muss vollständig sein, ein fehlerhaftes Kindobjekt wird jedoch übersprungen und gemeldet, statt die gesamte Anreicherung scheitern zu lassen. Alles: Lücken landen als NULL-Werte und nichts wird abgelehnt – aber der Entitätszustand folgt „last write wins“, die neueste Anreicherung ist die Zeile, sodass ein späterer unvollständiger Lauf löscht, was ein früherer gefüllt hat. Genau dieses Löschen sollen die beiden strengen Stufen verhindern.
Anreicherungen, die die Prüfung nicht bestehen, werden dennoch als Datensätze gespeichert und lösen weiterhin den Webhook record.created aus – mit database.saved auf false – und nennen Ihnen genau die fehlenden Pflichtfelder, sodass unvollständige Daten nie stillschweigend verschwinden. Zu jedem fehlenden Feld wird außerdem angegeben, ob ein Modell es als unbekannt deklariert oder es einfach ausgelassen hat: Ersteres verlangt nach einem stärkeren Modell, einer Websuche oder einem Quelldokument, Letzteres nach einem Blick auf das Schema oder die Eingabe. Nur die Datenbankschlüssel-Felder sind immer erforderlich: Eine Anreicherung ohne Schlüsselwert wird unabhängig von der Stufe abgelehnt.
Auf den strengen Stufen spiegelt ein Kontrollkästchen denselben Vertrag in Ihrer eigenen Datenbank wider – als NOT NULL-Spalten für jedes immer vorhandene Feld. Auf der strengsten Stufe werden auch die Fremdschlüssel erforderlicher Referenzen eingeschränkt – keiner zugelassenen Zeile können sie fehlen. Bei unvollständige Kindobjekte überspringen bleiben sie bewusst nullbar: Ein Listenelement, dem ein eigener Wert fehlt, wird verworfen, und eine gemeinsam genutzte 1:1-Referenz mit unvollständigem Ziel (das Stadion, dessen Eröffnungsjahr niemand kennt) wird abgekoppelt – dieses Ziel wird weder geschrieben noch aktualisiert, und die gespeicherte Zeile verweist dort auf nichts, wodurch genau in diese Fremdschlüsselspalten NULL geschrieben wird. Beides wird in der Anreicherungsantwort gemeldet, und Lücken in Feldern der obersten Ebene führen immer zur Ablehnung. Die Richtlinie nach dem ersten Sync zu ändern ist nie vergebliche Arbeit: Sie wird als abgesicherte Migration im Feed ausgeliefert und gegen die Zeilen validiert, die Ihre Datenbank bereits enthält.
Eine zweite Prüfung erkennt doppelte Identitäten: Wenn zwei Elemente derselben Liste auf denselben Datenbankschlüssel abgebildet werden — ein Modell erfindet eine ID für zwei verschiedene Unternehmen, oder ein Schlüssel unterscheidet sie nicht — kann nur eine Zeile existieren; also wird die letzte geschrieben und die früheren werden verworfen, nach derselben Last-Write-Wins-Regel wie überall sonst. Jede Kollision wird mit den identifizierenden Werten beider Elemente und einem Befund gemeldet: Ein Duplikat hat dieselben Werte wiederholt und nichts verloren, ein widersprüchliches Verwerfen hat die genannten Werte verloren — entweder hat das Modell dieselbe Sache mit abweichenden Werten wiederholt, oder es handelt sich um verschiedene Dinge und der Schlüssel benötigt eine unterscheidende Eigenschaft (eine Region, ein Jahr, eine Version). Die Liste bleibt am Datensatz erhalten, sodass ein Teilschreibvorgang auch lange nach dem Verschwinden der Antwort noch angibt, was verloren ging.
Eines sollten Sie wissen, bevor Sie erneut anreichern: Bei einer Liste, die zu ihrem übergeordneten Element gehört, gilt die Liste der neuesten Anreicherung als die maßgebliche Liste. Eine untergeordnete Zeile, die die neueste Antwort nicht wiederholt, wird aus Ihrer Datenbank gelöscht — so erreicht Sie eine echte Entfernung, und die Antwort meldet sie nicht. Das ist wichtig, wenn es sich um eine Liste handelt, die das Modell abruft, statt sie aufzuzählen: Fragen Sie zweimal nach den Isotopen eines Elements oder den Auszeichnungen einer Person, und die zweite Antwort kann kürzer ausfallen, wodurch Zeilen entfernt werden, die zutrafen. Führen Sie Ihren eigenen Verlauf, wenn Sie die Vereinigung aller Durchläufe benötigen.
Anreicherungen gelangen von selbst in eine verknüpfte Datenbank. Alles andere – ein Ergebnis, das die Aufnahmeprüfung abgelehnt hat, bevor Sie das Schema korrigiert haben, ein Lauf, den Sie bewusst ausgeschlossen haben, oder Ausgaben, die Sie zuerst prüfen oder korrigieren möchten – läuft über das Senden von Datensätzen an die Datenbank: Wählen Sie sie auf der Verlaufsseite aus oder rufen Sie die API aus einem Workflow auf.
Der Rundlauf. Reichern Sie mit ausgeschaltetem Database Sync an, formen oder bestätigen Sie das Ergebnis in Ihrem eigenen Workflow und senden Sie es dann. Was Sie senden, wird erneut gegen den veröffentlichten Vertrag des Schemas validiert und durchläuft dieselbe Aufnahmeprüfung wie eine Anreicherung – eine Einspeisung kann niemals schreiben, was eine Anreicherung nicht schreiben könnte.
Zwei Details, die Sie kennen sollten. Wenn Sie einen Datensatz unverändert senden, wird er unter diesem Datensatz gespeichert. Beim Senden einer geänderten Ausgabe entsteht ein neuer Datensatz, der auf das Original zurückverweist, denn Datensätze sind ein Audit-Trail: Sie ändern sich nie unter den Daten, die sie zitieren, sodass der Inhalt Ihrer Datenbank stets auf einen Datensatz mit genau diesen Werten zurückführbar ist. Und die Validierung verwendet den Vertrag in seinem heutigen Stand — hat sich das Schema seit der Erzeugung des Datensatzes weiterentwickelt, weist die Verlaufsseite vor dem Senden darauf hin.
Die Verlaufsseite zeigt außerdem pro Datensatz, ob er die Datenbank erreicht hat: gesendet, teilweise gesendet oder mit Begründung abgelehnt. Verfügbar über die Web-App, die API, MCP, n8n und Make.
Der Feed ist eine strikte FIFO-Warteschlange pro Datenbank: ein Fenster abrufen (optional mit Lease, sodass der Batch eines abgestürzten Workers vor allem Neueren erneut zugestellt wird), anwenden, bestätigen. Webhook-Benachrichtigungen werden entprellt – jedes neue Delta setzt einen Ruhephasen-Timer zurück, sodass eine Serie von Anreicherungen nur einmal gemeldet wird; eine konfigurierbare maximale Verzögerung begrenzt die Wartezeit, und eine vollständige Abrufseite löst sofort aus. Zwei Bereinigungsoptionen steuern, was Entity Enricher aufbewahrt: zugestellte Delta-Kopien bei der Bestätigung löschen und – zur Datenminimierung – den Entitätszustand selbst löschen, sobald jede mit dem Schema verknüpfte Datenbank ihn erhalten hat. Beide akzeptieren eine optionale Verzögerung in Tagen: Zugestellte Kopien bleiben dann noch so lange nach der Bestätigung erhalten (ein Replay-Fenster), und eine zugestellte Entität wird aufbewahrt, bis sie so lange ohne Aktualisierung geblieben ist; eine stündliche Bereinigung löscht, was abgelaufen ist. Beachten Sie: Die Bereinigung des Zustands ist Minimierung, keine Löschung: Anreicherungs-Datensätze bleiben bestehen, bis Sie sie löschen, und für die bereinigten Entitäten wird das anreicherungsübergreifende Zusammenführen deaktiviert.
Ein Prüfsummen-Endpunkt pro Tabelle ermöglicht es Ihnen, jederzeit zu überprüfen, ob Ihr Replikat konvergiert ist, ohne etwas erneut herunterladen zu müssen.
Alles befindet sich an einer Stelle in der App — Database Sync, direkt unterhalb von Verlauf in der Seitenleiste: Registrieren Sie eine Datenbank für ein beliebiges Schema (inklusive Prüfung des Datenbankschlüssels), verknüpfen oder trennen Sie Schemas, pausieren Sie den Anreicherungs-Feed eines verknüpften Schemas über dessen Schalter (keine neuen Daten und keine Benachrichtigungen bis zur Reaktivierung — Schema-Publikationen liefern weiterhin ihr DDL, und Anreicherungen, die während der Pause laufen, erreichen die Replik nur über ein erneutes Abrufen des Snapshots), bearbeiten Sie dessen Optionen, sehen Sie den Webhook-Endpunkt ein und lassen Sie sich dessen Signaturschlüssel anzeigen, laden Sie den Snapshot herunter, durchsuchen Sie den aktuellen Entitätsstand, prüfen Sie die Warteschlange ausstehender Deltas (schreibgeschützt — der Cursor Ihres Workflows wird nie verändert) und betrachten Sie ein Entity-Relationship-Diagramm der generierten Tabellen mit ihren Schlüsseln und Verknüpfungstabellen. Bei einem Sync über mehrere Datenbanken kann das Diagramm auf ein Schema fokussieren: Tabellen, Spalten und Verknüpfungen, die von den anderen Schemas gespeist werden, werden ausgegraut — bleiben aber an Ort und Stelle sichtbar —, sodass Sie genau sehen, was jedes Schema zu den gemeinsamen Tabellen beiträgt.
Wenn mehrere Datenbanken auf derselben Maschine landen, erspart Ihnen die Symbolleisten-Schaltfläche Sync-Hosts die Kopplungszeremonie pro Datenbank: Koppeln Sie die Maschine einmal, um ihr anschließend Registrierungen zuzuweisen. Der Host übernimmt jede davon, legt die physische Datenbank an, falls sie nicht existiert, und startet die Synchronisierung – so wird das Registrieren einer Datenbank zu einer Entscheidung, die Sie hier treffen, und nicht zu einer Terminal-Sitzung auf dem Server. Die Kopplung gilt pro Entity Enricher-Server, sodass eine Maschine mehrere Instanzen nebeneinander bedienen kann.
Eine Anweisung, die Ihre Datenbank ablehnt — meist wegen bereits vorhandener Duplikate unter einem neuen Unique-Index —, blockiert die dahinter wartende Warteschlange nicht. Der Batch dieser Anreicherung wird unter Quarantäne gestellt, der Feed läuft weiter, und der Batch erscheint im Tab Quarantäne zusammen mit der Anweisung, die Ihre Datenbank abgelehnt hat. Beheben Sie die Ursache und wählen Sie Erneut einspeisen — dabei wird die Entität aus ihrem aktuellen Zustand neu projiziert, statt eine veraltete Anweisung erneut abzuspielen — oder verwerfen Sie ihn.
GET /api/databases//changes?since=…&format=sql und anschließend POST /api/databases//ack.Sie nutzen Supabase? Unser Supabase MCP-Vergleich zeigt anhand von JSON und kleinen Tabellendiagrammen, wie die Beziehungs- und Sync-Regeln von EE einen Produktkatalog schützen.
Nichts in der Synchronisation läuft jemals auf Ihrem Datenbankserver — jeder oben genannte Pfad ist ein ausgehender Consumer, der sich mit der DSN verbindet, die Sie ihm geben. Azure Database for PostgreSQL, OVHcloud, AWS RDS, Supabase oder jede andere verwaltete Instanz funktioniert genau wie eine selbstgehostete: Richten Sie den Consumer auf die Cloud-DSN (verwaltete Provider erzwingen üblicherweise TLS, fügen Sie also sslmode=require hinzu) und wenden Sie an.
--dsn auf die verwaltete Instanz richtet, genügt.delta_available-Webhook weckt eine Azure Function / AWS Lambda / OVHcloud-Funktion, die den REST-Feed abruft, das SQL ausführt und bestätigt.Zwei Regeln halten jeden selbstgebauten Consumer sicher: Führen Sie die Statements jedes Batches der Reihe nach, in einer einzigen Transaktion aus und bestätigen Sie erst nach dem Commit. Deltas sind idempotent und revisionsgeschützt, daher bedeutet ein Absturz vor der Bestätigung einfach, dass der Batch erneut zugestellt wird und das erneute Anwenden konvergiert.
Datenbanken sind in kostenpflichtigen Tarifen verfügbar (der Tarif legt fest, wie viele Sie registrieren können). PostgreSQL ist der Start-Dialekt; jede Datenbank gibt ihren Dialekt an, MySQL / MariaDB, SQL Server und Oracle sind geplant.