Der Open-Source-Apply-Client für Schema-Datenbanken. Betreiben Sie ihn neben Ihrem eigenen PostgreSQL, koppeln Sie ihn einmal, und er hält diese Datenbank mit Ihren Enrichments konvergent — Bootstrap aus einem Snapshot, dann Anwendung eines Live-Delta-Feeds über einen einzigen ausgehenden WebSocket. Ihr Verbindungsstring verlässt niemals Ihren Rechner.
Jede Anweisung ist revisionsgeschützt, sodass ein erneut ausgelieferter Batch zu denselben Zeilen konvergiert. Ein SQL-Fehler setzt den Batch zurück und stoppt — ein fehlerhaftes Delta wird niemals stillschweigend übersprungen.
Der Client zieht Zustand, keine Operationen: Jedes Delta trägt die vollständige(n) aktuelle(n) Zeile(n) einer geänderten Entity als idempotentes INSERT … ON CONFLICT … DO UPDATE, sodass das Ziel selbst dann konvergiert, wenn ein Batch verpasst wurde.
Schema-Datenbanken lassen sich auf verschiedene Arten nutzen — n8n, Make.com, MCP, rohe Webhooks oder den REST-Delta-Feed. Der Sync-Client ist der vollständig automatisierte Weg: am wenigsten zu bauen und am wenigsten preiszugeben.
Kein n8n-Szenario, kein Cron, kein Glue-Code. Einmal koppeln, und es startet aus dem Snapshot und wendet dann jedes Delta an, sobald es eintrifft.
Der Verbindungsstring wird über die Kommandozeile übergeben oder lokal im Modus 600 gespeichert — er wird niemals an Entity Enricher gesendet. Der Client verbindet sich ausschließlich nach außen.
Jedes Delta ist ein idempotenter, revisionsgeschützter Upsert. Stirbt der Client mitten im Batch, wird der Batch nach Ablauf seiner Lease erneut ausgeliefert, und ein erneutes Anwenden konvergiert zu denselben Zeilen.
Ein SQL-Fehler macht den Batch rückgängig, meldet das fehlerhafte Delta auf der Seite Datenbanken und beendet den Prozess mit einem Exit-Code ungleich null — ein Poison-Delta kann niemals stillschweigend übersprungen werden.
Registrieren Sie zuerst eine Datenbank für ein Schema, koppeln Sie dann einen Client und führen Sie ihn neben Ihrer Datenbank aus.
Registrieren Sie auf der Seite Datenbanken eine Datenbank für das Schema, das Sie spiegeln möchten, und prüfen Sie deren Datenbankschlüssel. Siehe Datenbanken für das vollständige Modell. Dieser Schritt legt den Ziel-Dialekt fest, den der Client anwendet.
Laden Sie eine signierte Binärdatei von Releases herunter oder bauen Sie sie aus dem Quellcode (Go ≥ 1.23).
go build -o ee-database .
Quellcode und signierte Releases finden Sie unter TOT-Concept/ee-database (MIT).
Führen Sie ee-database pair aus. Ein Browser-Tab öffnet sich unter /database/connect mit einem Kurzcode — bestätigen Sie ihn und wählen Sie, welche Datenbank dieser Client synchronisieren soll.
ee-database pair --server https://entityenricher.ai Open this URL in your browser to confirm pairing: https://entityenricher.ai/database/connect?code=7QX-KP2 Code: 7QX-KP2 Waiting for confirmation...
Lieber ein Token? Stellen Sie eines auf der Seite „Datenbanken“ aus (Sync-Client → Client koppeln) und übergeben Sie es direkt: ee-database pair --server … <refresh-token>.
Beim ersten Lauf ruft der Client den .sql-Snapshot ab und wendet ihn an, verbindet sich dann und streamt Deltas. --save-dsn speichert die Verbindungszeichenfolge lokal, sodass spätere Läufe keine Argumente benötigen.
ee-database run --dsn "postgres://user:pass@localhost:5432/mydb" --save-dsn
„Next to“ bedeutet netzwerknah, nicht auf dem Datenbankserver: jede Maschine oder jeder Container, der die DSN erreichen kann, funktioniert — einschließlich cloud-verwaltetem PostgreSQL (Azure, OVHcloud, AWS RDS…), das üblicherweise TLS erzwingt: …/mydb?sslmode=require.
Deltas verlassen Entity Enricher über eine strikte FIFO-Outbox pro Datenbank. Der Server least das sichtbare Fenster für 120 Sekunden und pusht es als einen Batch; der Client wendet den gesamten Batch in einer einzigen Transaktion an und antwortet mit ack , was den Cursor vorrückt und sofort das nächste Fenster auslöst. Ein Client, der mitten im Batch ausfällt, ist durch den Ablauf des Lease und einen erneuten Push seitens des Servers abgedeckt — nichts geht verloren und nichts wird doppelt committet.
Bootstrap und Steady-State nutzen denselben Codepfad. Überspringen Sie den Bootstrap mit --skip-bootstrap, wenn Ihre Datenbank bereits befüllt ist.
Jede Anweisung trägt eine _sync_revision, sodass eine ältere Zeile niemals eine neuere überschreibt, auch nicht bei falscher Reihenfolge.
Ein SQL-Fehler speichert die ID des fehlerhaften Deltas auf der Seite Datenbanken → Karte Sync-Client, und der Prozess wird mit einem Exit-Code ungleich null beendet, damit Ihr Supervisor ihn neu starten kann.
Der Ziel-Dialekt wird durch die Schema-Datenbank-Registrierung in Entity Enricher festgelegt — der Client wendet genau das SQL an, das der Server rendert. PostgreSQL ist der Start-Dialekt; die Treiber für MySQL und SQLite sind bereits gebündelt, für den Zeitpunkt, an dem ihre SQL-Renderer erscheinen. Die Anwendung mehrerer Anweisungen wird pro Treiber gehandhabt (pgx Simple Protocol, MySQL multiStatements und CGO-freies SQLite).
Der Client initiiert den WebSocket über :443/wss. Ihr Datenbank-Host akzeptiert niemals eingehende Verbindungen — keine Ports zu öffnen, kein Ingress zu konfigurieren.
Anmeldedaten sind an eine einzige Schema-Datenbank gebunden. Ein erneutes Pairing rotiert sie und beendet die vorherige Live-Verbindung sofort.
Das 365-Tage-Refresh-Token (im Modus 600 gespeichert) wird gegen 15-minütige Zugriffstoken eingetauscht, die den WebSocket authentifizieren. Ein Widerruf in der Benutzeroberfläche trennt einen aktiven Client innerhalb von ~1 Sekunde.
Betreiben Sie den Client mit einer dedizierten Datenbankrolle, die auf das synchronisierte Schema beschränkt ist, sodass ein kompromittiertes Token nichts anderes berühren kann.
| Befehl | Was es tut |
|---|---|
| ee-database pair --server URL | Browser-bestätigtes Device-Code-Pairing. Wählen Sie aus, welche Datenbank synchronisiert werden soll. |
| ee-database pair --server URL <token> | Koppeln Sie mit einem auf der Seite „Datenbanken“ ausgestellten Token (headless-freundlich). |
| ee-database run --dsn DSN [--save-dsn] [--skip-bootstrap] | Bootstrap aus dem Snapshot (sofern nicht übersprungen), dann verbinden und Deltas anwenden. |
| ee-database run … --create-missing | Erstellen Sie die Zieldatenbank zuerst, wenn sie nicht existiert, indem Sie die Anmeldedaten des DSN selbst verwenden (postgres benötigt CREATEDB, mysql das CREATE-Recht; SQLite-Dateien werden ohnehin automatisch erstellt). |
| ee-database run … --create-missing --admin-dsn DSN | Erstellen Sie über eine Admin-Verbindung alles, was der Ziel-DSN benennt: die fehlende Rolle/den fehlenden Benutzer (mit dem Passwort des DSN) und die zugehörige Datenbank. Der Ziel-DSN benötigt dann keine Erstellungsrechte; der Admin-DSN wird niemals gespeichert. |
| ee-database run --all | Jede gekoppelte Datenbank gleichzeitig aus einem Prozess synchronisieren (jede benötigt einen gespeicherten DSN). |
| ee-database status | Kopplungsstatus, Server-URL und die gekoppelten Datenbanken anzeigen. |
| ee-database disconnect | Lokale Anmeldedaten einer Kopplung löschen. Widerrufen Sie serverseitig über die Benutzeroberfläche. |
| ee-database version | Druckversion. |
Anmeldedaten werden im Modus 600 gespeichert, ein Profil pro gekoppelter Datenbank, unter ~/.config/ee-database/profiles/ — koppeln Sie einmal pro Datenbank, und --database NAME wählt eine aus, wenn mehrere gekoppelt sind. Möchten Sie ganz ohne Automatisierung auskommen? Derselbe Feed ist einfaches REST: GET /api/databases//changes und anschließend POST /api/databases//ack — siehe Datenbanken.
Der Client ist MIT-lizenziert und liegt in einem öffentlichen Repository, sodass jeder genau prüfen kann, was gegen seine Datenbank ausgeführt wird.
Quelle: github.com/TOT-Concept/ee-database
Releases: github.com/TOT-Concept/ee-database/releases — jede Binärdatei wird vor der Veröffentlichung signiert.