El cliente de aplicación de código abierto para bases de datos de schema. Ejecútelo en cualquier máquina que pueda acceder a su propio PostgreSQL, empareje una vez y mantendrá esa base de datos convergente con sus enrichments: arrancando desde una instantánea y luego aplicando un flujo de deltas en vivo a través de un único WebSocket saliente. Su cadena de conexión nunca sale de esa máquina.
Cada instrucción está protegida por revisión, de modo que un lote reentregado converge a las mismas filas. Un error de SQL revierte el lote y se detiene: un delta corrupto nunca se omite de forma silenciosa.
El cliente extrae estado, no operaciones: cada delta transporta la(s) fila(s) actual(es) completa(s) de una entidad modificada como un INSERT … ON CONFLICT … DO UPDATE idempotente, de modo que el destino converge incluso si se omitió un lote.
Los database syncs se pueden consumir de varias formas: n8n, Make.com, MCP, webhooks sin procesar o el feed de deltas REST. El cliente de sync es la vía totalmente automatizada: lo que menos hay que construir y lo que menos se filtra.
Sin escenario de n8n, sin cron, sin código de pegamento. Empareje una vez y arranca desde el snapshot; luego aplica cada delta a medida que llega.
La cadena de conexión se pasa por la línea de comandos o se almacena localmente con modo 600: nunca se envía a Entity Enricher. El cliente solo se conecta hacia el exterior.
Cada delta es un upsert idempotente y protegido por revisión. Si el cliente falla a mitad de un lote, el lote se vuelve a entregar cuando expira su lease y volver a aplicarlo converge a las mismas filas.
Un error de SQL revierte el lote e informa del delta fallido. El servidor pone en cuarentena todo el lote de ese enriquecimiento y vuelve a enviar la cola sin él, de modo que el cliente permanece conectado y sigue aplicando: una fila defectuosa no puede bloquear todo lo que viene detrás, y el trabajo en cuarentena permanece listado hasta que usted lo resuelva.
Primero registre una base de datos en un schema, luego empareje un cliente y ejecútelo en una máquina que pueda acceder a su base de datos.
En la página Database Sync, registre una base de datos sobre el esquema que quiera replicar y revise sus claves de base de datos. Consulte Database Sync para ver el modelo completo. Este paso declara el dialecto de destino que aplicará el cliente.
Pegue esto en una terminal. El script verifica una firma cosign antes de instalar.
curl -fsSL https://entityenricher.ai/install-eedatabase.sh | sh
Windows: iwr -useb https://entityenricher.ai/install-eedatabase.ps1 | iex. O descargue un binario firmado desde Versiones, o compile desde el código fuente (Go ≥ 1.23): go build -o ee-database .
El código fuente y las versiones firmadas están en TOT-Concept/ee-database (MIT).
Ejecute ee-database pair. Se abre una pestaña del navegador en /database/connect con un código corto: confírmelo y elija qué base de datos debe sincronizar este cliente.
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...
¿Prefiere un token? Genere uno en la página Database Sync (Cliente de sincronización → Emparejar un cliente) y páselo directamente: ee-database pair --server … <refresh-token>.
En la primera ejecución, el cliente obtiene el snapshot .sql y lo aplica; luego se conecta y transmite los deltas. --save-dsn almacena la cadena de conexión localmente para que las ejecuciones posteriores no necesiten argumentos.
Cada ejecución también autocomprueba los permisos de aprovisionamiento del usuario (crear base de datos, DDL, DML) e informa del resultado en la tarjeta del cliente de Sync, de modo que un permiso ausente es visible antes de que los deltas no puedan aplicarse. Si aún no hay ningún esquema vinculado publicado, el cliente permanece conectado y espera: la primera publicación inicia el flujo por sí sola, sin necesidad de reiniciar.
ee-database run --dsn "postgres://user:pass@localhost:5432/mydb" --save-dsn
«Junto a» significa adyacente en la red, no en el servidor de base de datos: cualquier máquina o contenedor que pueda alcanzar el DSN funciona — incluido PostgreSQL gestionado en la nube (Azure, OVHcloud, AWS RDS…), que normalmente exige TLS: …/mydb?sslmode=require.
¿Varias bases de datos en una misma máquina? Un host de sincronización eleva un nivel la ceremonia de emparejamiento: empareje la máquina una vez y cada sincronización de base de datos que le asigne se reclama, se aprovisiona y se mantiene sincronizada automáticamente — registrar una nueva sincronización nunca requiere otra sesión de terminal. Requiere el cliente 1.5.0 o posterior, que se empareja una vez por servidor en lugar de una vez por máquina — de modo que un mismo host puede servir a varias instancias de Entity Enricher en paralelo.
En la página Database Sync, haga clic en el botón Sync hosts de la barra de herramientas y añada un host con el nombre de la máquina. Aparece un token de emparejamiento de un solo uso, mostrado una única vez e incrustado en un comando host pair listo para copiar y pegar, con pasos guiados de configuración.
Ejecute el comando en la máquina que puede acceder a su servidor de base de datos. El --dsn es una cadena de conexión base que nombra el servidor, sin nombre de base de datos: cada sincronización asignada deriva su propia base de datos a partir de ella. Como todo DSN, se almacena localmente en modo 600 y nunca se envía a Entity Enricher.
ee-database host pair --server https://entityenricher.ai \ --dsn "postgres://user:pass@host:5432/" <token>
El emparejamiento autocomprueba los permisos de aprovisionamiento del usuario (crear base de datos, DDL, DML) y falla de inmediato si falta un permiso. ¿Prefiere un usuario con privilegios mínimos? Añada --admin-dsn y el aprovisionamiento creará cada rol y base de datos que falte a través de la conexión de administrador: el DSN de administrador se usa solo en el momento del aprovisionamiento, nunca se almacena.
ee-database host run
El host mantiene un WebSocket de plano de control y reacciona a las asignaciones realizadas en la interfaz: elija el host al registrar una base de datos, o más tarde en la pestaña Resumen de la base de datos. Cada sincronización asignada se reclama, su base de datos se crea si no existe (con el nombre en snake_case a partir del nombre de la sincronización; puede anularlo por sincronización mediante database_names en el config.json del host) y luego se sincroniza mediante el bucle habitual que se describe abajo.
Una base de datos ya emparejada con otro cliente se notifica y se omite, nunca se toma el control. Revocar el host en la interfaz desconecta la máquina al instante, incluidas todas las credenciales por base de datos que había reclamado; las asignaciones y los datos ya sincronizados permanecen, de modo que un host reemparejado continúa donde se detuvo el anterior.
Los deltas salen de Entity Enricher a través de una estricta bandeja de salida FIFO por base de datos. El servidor concede la ventana visible durante 120 segundos y la envía como un único lote; el cliente aplica todo el lote en una sola transacción y responde ack , lo que hace avanzar el cursor y activa la siguiente ventana de inmediato. Un cliente que falla a mitad de un lote queda cubierto por la expiración de la concesión y un reenvío por parte del servidor: nada se pierde ni se confirma dos veces.
El arranque inicial y el estado estable comparten la misma ruta de código. Omita el arranque inicial con --skip-bootstrap si su base de datos ya está inicializada.
Cada sentencia lleva un _sync_revision para que una fila más antigua nunca sobrescriba a una más reciente, incluso fuera de orden.
Un error de SQL revierte el lote e informa del delta fallido junto con la sentencia completa que lo provocó. El servidor pone en cuarentena el lote de ese enriquecimiento y vuelve a enviar la cola sin él: el cliente sigue aplicando el resto. Solo un fallo que no identifique ningún delta termina con un código distinto de cero.
Cada ventana aplicada informa de la estructura que escribió, por tabla — así, dimensionar un reenriquecimiento nocturno nunca exige arqueología de logs sobre deltas ya confirmados y descartados.
applying 12 delta(s) (10831 .. 10842) in one transaction applied 12 delta(s) in 84ms — 38 statement(s): mushroom 4 upserts, mushroom_common_names 12 upserts + 4 prunes, mushroom_human_uses 14 upserts + 4 prunes acked up to delta 10842
Un upsert equivale a una fila, por lo que los recuentos son recuentos de filas; un prune es el único DELETE protegido por revisión que elimina las filas hijas o de unión que un nuevo payload ya no reclama. Las filas hijas se reconcilian in situ — nunca se borran ni se reinsertan. Añada --verbose para obtener una línea por delta, con su tipo de entidad, su tiempo real y su propia estructura.
El dialecto de destino lo fija el registro de la base de datos del schema en Entity Enricher: el cliente aplica el SQL que genere el servidor. PostgreSQL es el dialecto de lanzamiento; los renderizadores de MySQL / MariaDB, SQL Server y Oracle están previstos (el driver de MySQL ya viene incluido). La aplicación de sentencias múltiples se gestiona por driver (protocolo simple de pgx, multiStatements en MySQL).
Si la base de datos de destino ya existe, el login solo necesita CONNECT sobre la base de datos y USAGE + CREATE sobre el esquema de destino. (Desde PostgreSQL 15, public ya no concede CREATE a todo el mundo de forma predeterminada.)
Todo lo demás se deriva de la propiedad: el cliente crea por sí mismo las tablas de réplica, por lo que es su propietario, y la propiedad implica las lecturas y escrituras que necesitan los deltas de datos. La propiedad no es opcional: el feed también incluye sentencias de migración (ALTER TABLE …, CREATE INDEX …) que PostgreSQL restringe al propietario de la tabla, y ninguna combinación de permisos la sustituye.
Si las tablas de la réplica ya existen con un propietario distinto, la comprobación previa de permisos de la ejecución se supera igualmente —el usuario de conexión puede crear tablas nuevas—, pero el primer delta de migración falla. Transfiéralas con ALTER TABLE … OWNER TO <login> (o conceda al usuario de conexión pertenencia al rol propietario) en lugar de añadir permisos.
Una sentencia que su base de datos rechaza —la causa habitual es un duplicado preexistente bajo un nuevo índice único— no detiene el flujo. El lote se revierte, el cliente informa del delta fallido junto con la sentencia completa que lo provocó (nunca truncada) y el servidor pone en cuarentena el lote de ese enriquecimiento y vuelve a enviar la cola sin él. Su cliente sigue aplicando todo lo que viene después.
El trabajo en cuarentena permanece listado en la pestaña Cuarentena de la página Database Sync hasta que usted lo resuelva: corrija la causa en su base de datos y reinyecte — lo que reproyecta la entidad a partir de su estado actual en lugar de reejecutar la sentencia obsoleta — o descártelo si la fila ya no importa.
Un bootstrap fallido es distinto: la instantánea es una única transacción, por lo que nada se aplica parcialmente, y el cliente la guarda en el directorio de perfil del emparejamiento como snapshot-failed.sql (modo 0600, reemplazado en cada intento, eliminado tras el siguiente éxito) para que pueda inspeccionarla o reproducirla con psql -f.
El cliente inicia el WebSocket a través de :443/wss. El host de su base de datos nunca acepta conexiones entrantes: sin puertos que abrir ni ingress que configurar.
Una credencial está vinculada a un único database sync. Volver a emparejar la rota y expulsa al instante la conexión activa anterior.
El token de actualización de 365 días (almacenado con modo 600) se intercambia por tokens de acceso de 15 minutos que autentican el WebSocket. Revocarlo en la interfaz desconecta un cliente activo en ~1 segundo.
Un host gestionado se empareja con una clave corta eeh_… en lugar de con un JWT: el servidor solo guarda su hash, nunca caduca y únicamente termina cuando se revoca el host desde la interfaz.
Un bloqueo por perfil impide que dos procesos ejecuten el mismo emparejamiento a la vez; de lo contrario, se expulsarían mutuamente la sesión WebSocket en bucle.
Ejecute el cliente con un rol dedicado y limitado al esquema sincronizado, de modo que un token comprometido no pueda tocar nada más — pero deje que ese rol cree las tablas réplica para que sea su propietario. Las sentencias de migración exigen la propiedad, no los permisos concedidos.
| Comando | Qué hace |
|---|---|
| ee-database pair --server URL | Emparejamiento por código de dispositivo confirmado en el navegador. Elija qué base de datos sincronizar. |
| ee-database pair --server URL <token> | Empareje con un token emitido en la página Database Sync (compatible con entornos sin interfaz). |
| ee-database run --dsn DSN [--save-dsn] [--skip-bootstrap] | Arranque desde la instantánea (salvo que se omita), luego conéctese y aplique los deltas. |
| ee-database run … --create-missing | Crear primero la base de datos de destino cuando no exista, usando las credenciales del propio DSN (postgres necesita CREATEDB; mysql, el privilegio CREATE). |
| ee-database run … --create-missing --admin-dsn DSN | Inicialice a través de una conexión de administrador todo lo que nombra el DSN de destino: el rol o usuario que falta (con la contraseña del DSN) y la base de datos de su propiedad. Así, el DSN de destino no necesita permisos de creación; el DSN de administrador nunca se almacena. |
| ee-database run --all | Sincroniza todas las bases de datos emparejadas de forma concurrente desde un solo proceso (cada una necesita un DSN guardado). |
| ee-database run … --verbose | Registra la estructura de escritura y el tiempo real de cada delta, no solo el resumen por ventana. También lo acepta host run. |
| ee-database host pair --server URL --dsn BASE_DSN [--admin-dsn DSN] <token> | Empareje esta máquina una sola vez como host de sincronización gestionado — el DSN base identifica su servidor de base de datos (sin nombre de base de datos) y nunca sale de la máquina; el token procede del diálogo Sync hosts (el botón Sync hosts de la barra de herramientas en la página Database Sync). Un emparejamiento por servidor: puede emparejarse con varios servidores de Entity Enricher en paralelo. |
| ee-database host run [--server URL] | Modo gestionado: todas las database sync asignadas a este host se reclaman, se crean si faltan y se mantienen sincronizadas automáticamente — sin emparejamiento por base de datos y en todos los servidores emparejados a la vez (--server lo limita a uno). Si una base de datos ya está emparejada con otro cliente, se informa, nunca se toma el control. |
| ee-database host status / host disconnect [--server URL] | Muestre u olvide los emparejamientos de host de esta máquina. Revóquelos en el servidor desde la tarjeta Hosts de sincronización. |
| ee-database status | Muestra el estado del emparejamiento, la URL del servidor y las bases de datos emparejadas. |
| ee-database disconnect | Olvida las credenciales locales de un emparejamiento. Revoque en el servidor desde la interfaz. |
| ee-database version | Versión para imprimir. |
Las credenciales se almacenan en modo 600, con un perfil por cada base de datos emparejada, en ~/.config/ee-database/profiles/: empareje una vez por base de datos y use --database NAME para seleccionar una cuando haya varias emparejadas. ¿Prefiere prescindir por completo de la automatización? El mismo feed es REST puro: GET /api/databases//changes y luego POST /api/databases//ack — consulte Database Sync.
El cliente tiene licencia MIT y reside en un repositorio público para que cualquiera pueda auditar exactamente qué se ejecuta contra su base de datos.
Código fuente: github.com/TOT-Concept/ee-database
Versiones: github.com/TOT-Concept/ee-database/releases — cada binario se firma con cosign antes de su publicación.
Audite el instalador: curl -fsSL https://entityenricher.ai/install-eedatabase.sh | less