Vincule una base de datos a un esquema y Entity Enricher mantiene sus entidades enriquecidas como tablas relacionales de su propiedad: una tabla real de empresa con una columna de ingresos, no un archivo de exportación. Descargue una vez una instantánea SQL lista para ejecutar y luego mantenga su base de datos convergente con un feed incremental de deltas de upserts idempotentes.
Almacene una vez, proyecte a demanda. Los enriquecimientos escriben el estado actual de la entidad en la capa de entidades; cada base de datos vinculada es una proyección de ese estado, entregada como una instantánea única más un flujo de deltas que usted confirma. Editar un esquema cuesta una reproyección, nunca una migración de datos.
database_sync: false); los enriquecimientos de otros usuarios se enrutan con normalidad..sql (tablas + datos) y aplíquela a su PostgreSQL. El DDL incluye índices de join y claves foráneas (las filas hijas y de enlace se eliminan en cascada cuando se elimina una entidad). El encabezado del archivo le indica desde qué cursor delta reanudar.Cada tipo de entidad tiene una Clave de base de datos — el conjunto de columnas que sus tablas usan como índice único y destino de conflicto en los upserts. Al vincular una base de datos, una pasada de clasificación con IA propone todo el modelo de base de datos (claves, tipos de columna, índices, propiedad) para que usted lo revise, con un criterio simple de reserva: el ID semántico del objeto, si lo tiene; en su defecto, un campo tipo Id (id, product_id, …); y si no, las claves naturales del objeto. En sus tablas, un ID semántico llega como una columna semantic_id — el nombre id queda libre para su propio uso. Puede cambiarlos en cualquier momento en la pestaña “Modelo” de la base de datos — un cambio equivalente a una migración una vez publicado: vuelva a descargar la instantánea después. Nada llega a su base de datos hasta que el esquema se publique desde esa pestaña (vincular por sí solo no envía tablas ni filas).
Una clave de base de datos nunca admite valores nulos. Un valor nulo no coincide con ninguna fila, por lo que, en lugar de actualizar la entidad, insertaría un nuevo duplicado en cada enriquecimiento; por eso, un enriquecimiento cuya clave vuelve vacía se rechaza en lugar de guardarse. El editor mantiene separadas las dos marcas, y un esquema que active ambas se rechaza al guardarlo o al vincular una base de datos, indicando las dos formas de solucionarlo: haga que la propiedad esté siempre presente, o base la clave del tipo en una propiedad distinta.
Cuando una clave de base de datos es un campo de texto enriquecido y no un ID semántico, el valor almacenado será la respuesta del modelo, no el texto que usted envió. Identificar una empresa como Embraer en su solicitud no fija ese campo: el enriquecimiento puede responder Embraer S.A. — una grafía corregida, un sufijo jurídico ampliado, un desambiguador omitido — y eso es lo que actúa como clave de la fila. Por eso, buscar la fila por el valor que envió puede no encontrarla (utilice los entity_keys devueltos con cada enriquecimiento guardado), y una ejecución posterior que lo formule de otro modo es una clave distinta: inserta una segunda fila en lugar de actualizar la suya. Esto es lo esperable en cualquier clave formada por texto enriquecido. La solución es un ID semántico en ese tipo: las variantes de un mismo nombre se resuelven en una única identidad estable, de modo que la fila se mantiene sea cual sea la grafía que use el modelo. Actívelo al generar el esquema — añadirlo después obliga a editar todos los objetos.
Los objetos anidados dentro de arreglos se convierten en sus propias tablas, con filas de unión que conservan el orden; los objetos de valor sin identidad permanecen aplanados en las columnas de su objeto padre. Los nombres de las propiedades se usan textualmente (entrecomillados): los nombres de sus columnas son los nombres de las propiedades de su schema, abreviados solo cuando una ruta anidada superaría lo que PostgreSQL puede nombrar.
La proyección es determinista: el mismo esquema siempre se asigna a las mismas tablas y columnas. Los nombres de propiedad se convierten en nombres de columna literalmente (entre comillas); los nombres de tipo se pasan a snake_case para formar nombres de tabla (VideoGame → video_game). La única excepción es la longitud: PostgreSQL no puede contener un identificador de más de 63 bytes, por lo que una ruta profundamente anidada acorta sus objetos padre para que quepa (morphological_description_ → morpdesc_): el mismo prefijo para cada columna de ese objeto, mostrado y editable en la pestaña Modelo antes de vincular. Una propiedad también puede eliminar por completo su prefijo para coincidir con una columna que su base de datos ya tenga (product_identifiers.stock_keeping_unit → sku): el conmutador de vínculo junto al nombre en la pestaña Modelo. Cada tabla lleva una columna _sync_revision que se usa para mantener las reproducciones convergentes.
| En su esquema | En su base de datos |
|---|---|
| Objeto con identidad (ID semántico o claves) | Su propia tabla; las claves de la base de datos se convierten en el índice único y el destino del upsert |
| Campo escalar (cadena, número, booleano) | Una columna tipada (TEXT, BIGINT, NUMERIC, BOOLEAN) |
| Conjunto cerrado (un campo limitado a una lista de valores) | Una simple columna TEXT — sin CHECK, sin tipo enum de base de datos. La lista se aplica cuando responde la IA, por lo que añadir un valor más adelante nunca migra su base de datos. Añada su propia restricción si lo desea — la sincronización nunca la toca |
| Campo que admite o no admite valores nulos | Un campo no anulable se convierte de forma predeterminada en una columna NOT NULL, junto con el control de calidad de abajo: con el control más estricto, las referencias obligatorias también reciben claves foráneas NOT NULL; desactive la imposición —al registrar, o más tarde: un cambio posterior a la primera sincronización se publica como una migración protegida en el feed— para mantener todas las columnas anulables y dejar que sea el control el único que exija la completitud |
| Campo multilingüe | Una columna JSONB que contiene todos los idiomas |
| Objeto de valor incrustado (sin identidad) | Aplanado en columnas con prefijo (dimensions_width) |
| Array de objetos de valor | Una tabla secundaria referenciada por la principal, ordenada, con eliminación en cascada |
Array de entidades / relación $ref | Una tabla de unión que enlaza las filas de origen y destino, conservando el orden |
Campo clave (identifying) | Un índice secundario para búsquedas rápidas |
| Índice orientado a consultas (lista ordenada de campos) | Un índice multicolumna por cada forma declarada, ordenado como la consulta de pantalla de lista a la que sirve — primero las facetas y los conjuntos cerrados, al final la columna de ordenación o de rango, incluidos los campos multilingües (esa forma se despliega una vez por cada idioma que su base de datos haya recibido); propuesto por la fase de clasificación con un motivo, ajustado en la pestaña «Modelo», varios por entidad |
| Campo de búsqueda (intención de índice) | Un índice de trigramas (pg_trgm) sobre el texto que sus cuadros de búsqueda comparan por fragmentos — por idioma y sin límite en las columnas multilingües; nunca sobre un valor de lista desplegable, que corresponde más bien a un índice con la forma de la consulta (incluidos los multilingües — ese índice se despliega una vez por cada idioma que su base de datos haya recibido); se omite (sin efecto) en las réplicas sin la extensión hasta que un propietario de la base de datos la instale |
| Par de coordenadas (latitud + longitud) | Un único índice espacial sobre el par (GiST nativo de PostgreSQL, sin extensión) — consultas por radio, de vecino más cercano y de ventana de mapa |
| Par de intervalo (límite inicial + final) | Un único índice de rango sobre el par — consultas de solapamiento y de "qué valor estaba vigente en esta fecha" |
Una base de datos puede sincronizar más de un esquema. Los tipos de entidad con el mismo nombre en los esquemas vinculados van a parar a la misma tabla, fusionados por su clave de base de datos: los enriquecimientos de cada esquema actualizan solo sus propias columnas, de modo que una empresa enriquecida por dos esquemas se convierte en una única fila que contiene ambos conjuntos de columnas. Los tipos exclusivos de un esquema simplemente añaden sus propias tablas, entregadas mediante un delta de migración automático en el feed, sin necesidad de volver a descargar nada.
Cuando vincula un esquema, un paso de comparación muestra exactamente qué tablas se fusionarán (con sus claves y columnas añadidas) y cuáles son nuevas; un esquema que comparte una tabla adopta las claves de base de datos existentes de esa tabla, que se muestran para su revisión. Si los esquemas no comparten nada, el flujo sugiere una base de datos dedicada en su lugar. Desvincular un esquema nunca afecta a su base de datos: las tablas sincronizadas permanecen.
Desvincular un esquema, o eliminar una sincronización, deja dos cosas de nuestro lado: el estado de entidad almacenado que ya nada escribe y las propiedades de base de datos que lleva el esquema (claves de base de datos, tipos de columna, índices, propiedad). Ambas confirmaciones ofrecen eliminarlas, y solo para los esquemas que se quedan sin ninguna base de datos: uno que siga sincronizado en otro lugar lo conserva todo. El esquema en sí, sus registros de enriquecimiento y sus costes nunca se ven afectados.
Un esquema vinculado tiene un contrato publicado: la versión que realmente usan sus enriquecimientos y su base de datos. Editar el esquema solo modifica una copia de trabajo: los cambios de redacción se aplican automáticamente, mientras que los cambios estructurales (nuevos campos, cambios de tipo o de clave) esperan a que pulse Publicar. Al publicar se previsualiza el impacto exacto y se envía la migración adecuada al feed de deltas: las columnas nuevas llegan como deltas ALTER TABLE, y los cambios más importantes (una nueva clave de base de datos, un cambio de tipo) se ejecutan como migraciones protegidas contra su propia base de datos; si los datos las bloquean (un valor de clave ausente o duplicado), el feed se pausa indicando el problema exacto y reintenta automáticamente en cuanto lo corrige.
La publicación se encuentra en la pestaña Model de la base de datos (el Editor de flujos de trabajo muestra un aviso que apunta allí mientras el esquema está vinculado). Antes de publicar, muestra ambas partes: el contrato en el que está su base de datos hoy y una comparación de todo lo que cambiaría su copia de trabajo. ¿No le convence una edición? Revertir a lo publicado restaura el contrato —es reversible, y el borrador que dejó a un lado se puede restaurar durante 24 horas.
Revincular un esquema que se editó mientras estaba desvinculado funciona igual: la sincronización recuerda lo que su base de datos ya tiene y envía solo la diferencia, además de una actualización de la instantánea para las filas escritas en el intervalo. Nunca hace falta un DROP manual.
La misma promesa cubre nuestras propias actualizaciones. Cuando una nueva versión mejora la forma en que los esquemas se asignan a las tablas, su sincronización se migra automáticamente: los cambios aditivos llegan al feed por sí solos. Si una actualización reestructurara tablas que ya contiene, nunca tocamos sus datos sin avisar: la entrega se pausa y su página de Database Sync le pide que la aplique, mostrando exactamente qué cambia primero.
El enriquecimiento multilingüe también es de primer nivel aquí: los valores localizados llegan como columnas JSONB que contienen todos los idiomas del enriquecimiento — {"en": "Headache", "fr": "Céphalée"} — de modo que una sola base de datos sirve todas sus configuraciones regionales a la vez. Elija un idioma directamente en sus consultas (name->>'fr'), y las cargas útiles de delta en JSON incluyen los mismos objetos indexados por idioma.
Cada base de datos responde a una pregunta al registrarse: cuando un enriquecimiento vuelve con huecos —campos no anulables sin rellenar—, ¿qué se escribe? Las tres respuestas forman una escala. Nada: basta un hueco en cualquier punto, incluido el interior de un objeto anidado, para que la entidad se rechace. La entidad, sin sus hijos incompletos (la opción predeterminada): la fila de la propia entidad debe estar completa, pero un hijo defectuoso se omite y se notifica en lugar de hundir todo el enriquecimiento. Todo: los huecos se escriben como NULL y no se rechaza nada, pero el estado de la entidad funciona por última escritura, el último enriquecimiento es la fila, así que una ejecución parcial posterior borra lo que rellenó una anterior. Evitar ese borrado es precisamente la razón de ser de los dos niveles estrictos.
Los enriquecimientos que no superan el filtro se guardan igualmente como registros y siguen disparando el webhook record.created —con database.saved en false— indicando exactamente qué campos obligatorios faltaban, de modo que los datos incompletos nunca desaparecen de forma silenciosa. Cada campo ausente indica además si un modelo lo declaró desconocido o simplemente lo omitió: lo primero pide un modelo más potente, búsqueda web o un documento fuente; lo segundo, una revisión del esquema o de la entrada. Solo los campos de la clave de base de datos son siempre obligatorios: un enriquecimiento al que le falte un valor de clave se rechaza sea cual sea el nivel.
En los niveles estrictos, una casilla replica ese mismo contrato en su propia base de datos como columnas NOT NULL en cada campo siempre presente. Con el nivel más estricto también se restringen las claves foráneas de las referencias obligatorias: ninguna fila admitida puede carecer de ellas. Con omitir hijos incompletos siguen siendo anulables, y es deliberado: un elemento de lista al que le falta un valor propio se descarta, y una referencia uno a uno compartida cuyo destino está incompleto (el estadio cuyo año de inauguración nadie conoce) se desvincula: ese destino no se escribe ni se actualiza, y la fila guardada no enlaza con nada, lo que escribe NULL exactamente en esas columnas de clave foránea. Ambos casos se notifican en la respuesta del enriquecimiento, y los huecos en campos de primer nivel siempre provocan el rechazo. Cambiar la política después de la primera sincronización nunca supone trabajo perdido: se publica como una migración protegida en el feed, validada contra las filas que su base de datos ya contiene.
Una segunda barrera detecta las identidades duplicadas: cuando dos elementos de una misma lista se resuelven en la misma clave de base de datos —un modelo que inventa un mismo id para dos empresas distintas, o una clave que no las distingue— solo puede existir una fila, así que se escribe la última y se descartan las anteriores, la misma regla de «gana la última escritura» que en el resto del sistema. Cada colisión se notifica con los valores identificadores de ambos elementos y un veredicto: un duplicado repitió los mismos valores y no perdió nada; un descarte conflictivo perdió los valores que indica: o bien el modelo repitió una misma cosa con valores ruidosos, o bien se trata de cosas distintas y la clave necesita una propiedad discriminante (una región, un año, una versión). La lista se conserva en el registro, de modo que una escritura parcial sigue indicando qué se perdió mucho después de que la respuesta haya desaparecido.
Una cosa que conviene saber antes de volver a enriquecer: para una lista que pertenece a su elemento padre, la lista del enriquecimiento más reciente es la lista. Una fila secundaria que la última respuesta no repite se elimina de su base de datos: así es como una eliminación genuina llega hasta usted, y la respuesta no la informa. Esto importa cuando la lista es una que el modelo recuerda en lugar de enumerar: pida dos veces los isótopos de un elemento o los premios de una persona y la segunda respuesta puede ser más corta, lo que elimina filas que eran verdaderas. Conserve su propio historial si necesita la unión de todas las ejecuciones.
Los enriquecimientos llegan por sí solos a una base de datos vinculada. Todo lo demás —un resultado que la puerta rechazó antes de que corrigiera el esquema, una ejecución que dejó fuera a propósito o una salida que quiere revisar o corregir primero— pasa por el envío de registros a la base de datos: selecciónelos en la página Historial o llame a la API desde un flujo de trabajo.
El ciclo completo. Enriquezca con Database Sync desactivado, transforme o apruebe el resultado en su propio flujo de trabajo y luego envíelo. Lo que envía se vuelve a validar contra el contrato publicado del esquema y pasa por la misma puerta de admisión que atraviesa un enriquecimiento: una inyección nunca puede escribir lo que un enriquecimiento no podría.
Dos detalles que conviene conocer. Enviar un registro sin modificar lo almacena bajo ese registro. Enviar un resultado modificado crea un nuevo registro que apunta al original, porque los registros son una pista de auditoría: nunca cambian bajo los datos que los citan, así que lo que contiene su base de datos siempre es trazable hasta un registro con exactamente esos valores. Y la validación usa el contrato tal como es hoy: si el esquema evolucionó desde que se produjo el registro, la página Historial lo señala antes de que envíe.
La página Historial también muestra, por registro, si llegó a la base de datos: enviado, enviado parcialmente o rechazado con el motivo. Disponible desde la aplicación web, la API, MCP, n8n y Make.
El feed es una cola FIFO estricta por base de datos: recuperar una ventana (opcionalmente reservada, de modo que el lote de un worker caído se vuelva a entregar antes que cualquier otro más reciente), aplicarla y confirmarla. Las notificaciones de webhook usan antirrebote: cada nuevo delta reinicia un temporizador de periodo de inactividad, de modo que una ráfaga de enriquecimientos se anuncia una sola vez, un retardo máximo configurable limita la espera y una página de recuperación completa se envía de inmediato. Dos opciones de purga controlan qué conserva Entity Enricher: eliminar las copias de deltas entregadas al confirmarlas y —para minimizar los datos— eliminar el propio estado de la entidad una vez que todas las bases de datos vinculadas al esquema lo hayan recibido. Cada una admite un retardo opcional en días: las copias entregadas se conservan ese tiempo tras la confirmación (una ventana de repetición) y una entidad entregada se mantiene hasta que pase ese tiempo sin actualizarse; una purga horaria elimina lo caducado. Tenga en cuenta que la purga de estado es minimización, no borrado: los registros de enriquecimiento permanecen hasta que usted los elimine, y desactiva la fusión entre enriquecimientos para las entidades purgadas.
Un endpoint de checksum por tabla le permite verificar en cualquier momento que su réplica convergió, sin necesidad de volver a descargar nada.
Todo está en un mismo lugar dentro de la aplicación: Database Sync, justo debajo de Historial en la barra lateral: registre una base de datos en cualquier esquema (con la revisión de la clave de base de datos), vincule o desvincule esquemas, pause el flujo de enriquecimiento de un esquema vinculado con su interruptor (sin datos nuevos ni notificaciones hasta reactivarlo: las publicaciones de esquema siguen enviando su DDL, y los enriquecimientos ejecutados durante la pausa solo llegan a la réplica mediante una nueva descarga de la instantánea), edite sus opciones, consulte el endpoint del webhook y revele su clave de firma, descargue la instantánea, explore el estado actual de las entidades, inspeccione la cola de deltas pendientes (solo lectura: nunca se toca el cursor de su flujo de trabajo) y vea un diagrama entidad-relación de las tablas generadas con sus claves y uniones. En una sincronización con varias bases de datos, el diagrama puede centrarse en un solo esquema: las tablas, columnas y vínculos alimentados por los demás esquemas se atenúan —siguen visibles en su sitio— para que vea exactamente qué aporta cada esquema a las tablas compartidas.
Cuando varias bases de datos coinciden en la misma máquina, el botón Hosts de sincronización de la barra de herramientas elimina la ceremonia de emparejamiento por cada base de datos: empareje esa máquina una vez y luego asígnele los registros de bases de datos. El host reclama cada uno, crea la base de datos física si no existe y empieza a sincronizar, de modo que registrar una base de datos pasa a ser una decisión que toma aquí, no una sesión de terminal en el servidor. El emparejamiento es por servidor de Entity Enricher, así que una misma máquina puede dar servicio a varias instancias en paralelo.
Una sentencia que su base de datos rechaza —la causa habitual son duplicados preexistentes bajo un nuevo índice único— no bloquea la cola que viene detrás. El lote de ese enriquecimiento se pone en cuarentena, el flujo sigue corriendo y el lote aparece en la pestaña Cuarentena con la sentencia que su base de datos rechazó. Corrija la causa y reinyecte —lo que vuelve a proyectar la entidad desde su estado actual en lugar de repetir una sentencia obsoleta— o descártelo.
GET /api/databases//changes?since=…&format=sql y luego POST /api/databases//ack.¿Utiliza Supabase? Nuestra comparación con Supabase MCP muestra cómo las reglas de relaciones y de sincronización de EE protegen un catálogo de productos, con JSON y pequeños diagramas de tablas.
Nada de la sincronización se ejecuta nunca en su servidor de base de datos — cada ruta anterior es un consumidor saliente que se conecta al DSN que usted le indique. Azure Database for PostgreSQL, OVHcloud, AWS RDS, Supabase o cualquier otra instancia gestionada funciona exactamente igual que una autoalojada: apunte el consumidor al DSN de la nube (los proveedores gestionados suelen exigir TLS, así que añada sslmode=require) y aplique.
--dsn a la instancia gestionada.delta_available despierta una función Azure Function / AWS Lambda / OVHcloud que obtiene el feed REST, ejecuta el SQL y confirma.Dos reglas mantienen seguro cualquier consumidor artesanal: ejecute las sentencias de cada lote en orden, dentro de una única transacción, y confirme solo después del commit. Los deltas son idempotentes y están protegidos por revisión, de modo que un fallo antes de la confirmación simplemente implica que el lote se vuelve a entregar y su reaplicación converge.
Las bases de datos están disponibles en los planes de pago (el plan determina cuántas puede registrar). PostgreSQL es el dialecto de lanzamiento; cada base de datos declara su dialecto, y están previstos MySQL / MariaDB, SQL Server y Oracle.