데이터베이스를 스키마에 연결하면 Entity Enricher가 강화된 엔티티를 사용자가 소유한 관계형 테이블로 유지합니다: 내보내기 파일이 아니라 revenue 열이 있는 실제 company 테이블입니다. 바로 실행 가능한 SQL 스냅샷을 한 번 다운로드한 다음, 멱등 업서트의 증분 델타 피드로 데이터베이스를 계속 수렴 상태로 유지하세요.
한 번 저장하고, 필요 시 투영합니다. 보강은 현재 엔터티 상태를 엔터티 레이어에 기록합니다. 연결된 각 데이터베이스는 해당 상태의 투영으로, 일회성 스냅샷과 사용자가 확인(ack)하는 델타 피드로 제공됩니다. 스키마를 편집하면 데이터 마이그레이션이 아니라 재투영 비용이 발생합니다.
database_sync: false를 전달합니다). 다른 사용자의 강화는 정상적으로 라우팅됩니다..sql 스냅샷(테이블 + 데이터)을 다운로드하여 PostgreSQL에 적용하세요. DDL에는 조인 인덱스와 외래 키가 포함되어 있습니다(엔티티가 삭제되면 하위 행과 링크 행이 캐스케이드로 삭제됩니다). 파일 헤더에서 어느 델타 커서부터 재개해야 하는지 확인할 수 있습니다.각 엔터티 유형에는 데이터베이스 키가 있습니다 — 테이블이 고유 인덱스이자 upsert 충돌 대상으로 사용하는 컬럼 집합입니다. 데이터베이스를 연결하면 AI 분류 과정이 데이터베이스 모델 전체(키, 컬럼 유형, 인덱스, 소유권)를 제안하여 검토하도록 하며, 그렇지 않은 경우 간단한 우선순위를 따릅니다: 객체에 시맨틱 ID가 있으면 그것을, 없으면 Id 형태의 필드(id, product_id, …)를, 그것도 없으면 객체의 자연 키를 사용합니다. 테이블에서 시맨틱 ID는 semantic_id 컬럼으로 들어오며, id라는 이름은 직접 사용할 수 있도록 비워 둡니다. 데이터베이스의 “모델” 탭에서 언제든지 변경할 수 있지만, 게시된 후에는 마이그레이션 수준의 변경이므로 이후 스냅샷을 다시 다운로드하세요. 해당 탭에서 스키마를 게시하기 전까지는 데이터베이스에 아무것도 반영되지 않습니다(연결만으로는 테이블도 행도 생성되지 않습니다).
데이터베이스 키는 절대 null을 허용하지 않습니다. null 값은 어떤 행과도 일치하지 않으므로, 엔티티를 업데이트하는 대신 강화할 때마다 새로운 중복 항목을 삽입하게 됩니다 — 그래서 키가 비어 있는 상태로 반환되는 강화는 저장되지 않고 거부됩니다. 편집기는 두 플래그를 서로 분리해서 관리하며, 두 가지를 모두 설정한 스키마는 저장하거나 데이터베이스를 연결할 때 거부되고, 이를 해결하는 두 가지 방법을 안내합니다: 해당 속성을 항상 존재하도록 만들거나, 다른 속성을 기준으로 타입의 키를 지정하세요.
데이터베이스 키가 시맨틱 ID가 아니라 보강된 텍스트 필드인 경우, 저장되는 값은 보낸 텍스트가 아니라 모델의 답변입니다. 요청에서 회사를 Embraer로 지정해도 해당 필드가 고정되지는 않습니다. 보강 결과가 Embraer S.A.로 응답할 수 있으며(철자 교정, 법인 접미사 확장, 구분자 제거 등), 행의 키가 되는 값은 바로 그 값입니다. 따라서 보낸 값으로 행을 조회하면 찾지 못할 수 있으므로 저장된 보강마다 반환되는 entity_keys를 사용하세요. 또한 이후 실행에서 표현이 달라지면 다른 키가 되어 기존 행을 업데이트하는 대신 두 번째 행을 삽입합니다. 이는 보강된 텍스트로 만든 모든 키에서 나타나는 동작입니다. 해결책은 해당 유형에 시맨틱 ID를 사용하는 것입니다. 한 이름의 여러 변형이 하나의 안정적인 식별자로 수렴하므로, 모델이 어떻게 표기하든 행이 유지됩니다. 스키마를 생성할 때 활성화하세요. 나중에 추가하려면 모든 객체를 수정해야 합니다.
배열 안에 중첩된 객체는 순서를 보존하는 연결 행과 함께 각자의 테이블이 됩니다. 식별자가 없는 값 객체는 부모의 컬럼에 병합된 상태로 유지됩니다. 속성 이름은 그대로(따옴표로 묶여) 사용됩니다 — 컬럼 이름은 스키마의 속성 이름이며, 중첩 경로가 PostgreSQL이 이름 붙일 수 있는 한도를 넘는 경우에만 축약됩니다.
투영은 결정론적입니다 — 동일한 스키마는 항상 동일한 테이블과 컬럼으로 매핑됩니다. 속성 이름은 그대로 컬럼 이름이 되고(따옴표로 감쌈), 타입 이름은 snake_case로 변환되어 테이블 이름이 됩니다(VideoGame → video_game). 유일한 예외는 길이입니다. PostgreSQL은 63바이트를 넘는 식별자를 담을 수 없으므로, 깊이 중첩된 경로는 상위 객체를 줄여서 맞춥니다(morphological_description_ → morpdesc_) — 해당 객체의 모든 컬럼에 동일한 접두사가 적용되며, 연결하기 전에 Model 탭에서 확인하고 편집할 수 있습니다. 속성은 접두사를 완전히 없애서 데이터베이스에 이미 있는 컬럼과 일치시킬 수도 있습니다(product_identifiers.stock_keeping_unit → sku) — Model 탭에서 이름 옆의 연결 토글을 사용합니다. 모든 테이블에는 재생을 수렴 상태로 유지하는 데 사용되는 _sync_revision 컬럼이 있습니다.
| 스키마에서 | 데이터베이스에서 |
|---|---|
| 식별자를 가진 객체 (시맨틱 ID 또는 키) | 자체 테이블을 가지며, 데이터베이스 키가 고유 인덱스 및 upsert 대상이 됩니다 |
| 스칼라 필드(문자열, 숫자, 불리언) | 타입이 지정된 컬럼(TEXT, BIGINT, NUMERIC, BOOLEAN) |
| 닫힌 집합(값 목록으로 제한된 필드) | 일반 TEXT 컬럼입니다 — CHECK도, 데이터베이스 enum 타입도 없습니다. 목록은 AI가 답변할 때 적용되므로, 나중에 값을 추가해도 데이터베이스가 마이그레이션되지 않습니다. 제약 조건이 필요하면 직접 추가하세요 — 동기화는 이를 건드리지 않습니다 |
| Nullable 또는 non-nullable 필드 | 널을 허용하지 않는 필드는 기본적으로 NOT NULL 컬럼이 되며, 아래의 품질 게이트와 함께 적용됩니다 — 가장 엄격한 게이트에서는 필수 참조의 외래 키에도 NOT NULL이 적용됩니다. 이 적용을 해제하면 — 등록 시점에, 또는 나중에: 첫 동기화 이후의 변경은 피드에 보호된 마이그레이션으로 반영됩니다 — 모든 컬럼이 널을 허용하게 되고 완전성은 게이트만으로 강제됩니다 |
| 다국어 필드 | 모든 언어를 담는 하나의 JSONB 컬럼 |
| 임베디드 값 객체(식별자 없음) | 접두사가 붙은 컬럼으로 평탄화됩니다 (dimensions_width) |
| 값 객체 배열 | 부모를 키로 하는 자식 테이블, 정렬되며 삭제 시 연쇄 적용됩니다 |
엔터티 배열 / $ref 관계 | 소스와 대상 행을 연결하는 조인 테이블, 순서가 유지됩니다 |
키 필드 (identifying) | 빠른 조회를 위한 보조 인덱스 |
| 쿼리 형태 인덱스(순서 있는 필드 목록) | 선언된 형태마다 다중 컬럼 인덱스가 하나씩 생성되며, 이를 사용하는 목록 화면 쿼리와 같은 순서로 정렬됩니다 — 패싯과 닫힌 집합이 먼저, 정렬 또는 범위 컬럼이 마지막이고 다국어 필드도 포함됩니다(그러한 형태는 데이터베이스가 받은 언어마다 하나씩 배포됩니다). 분류 단계에서 이유와 함께 제안되고 “모델” 탭에서 관리하며, 엔터티당 여러 개를 둘 수 있습니다 |
| 검색 필드(인덱스 의도) | 검색창에서 조각 단위로 일치시키는 텍스트에 적용되는 트라이그램 인덱스(pg_trgm) — 다국어 컬럼에서는 언어별로 생성되며 개수 제한이 없습니다. 드롭다운 값에는 절대 사용하지 않으며, 그런 값은 쿼리 형태 인덱스에 속합니다(다국어 값 포함 — 그러한 인덱스는 데이터베이스가 받은 언어마다 하나씩 배포됩니다). 확장이 설치되지 않은 복제본에서는 데이터베이스 소유자가 설치할 때까지 건너뜁니다(아무 작업 없음) |
| 좌표 쌍(위도 + 경도) | 쌍 전체에 대한 하나의 공간 인덱스(PostgreSQL 기본 GiST, 확장 불필요) — 반경, 최근접 이웃, 지도 뷰포트 조회에 사용합니다 |
| 구간 쌍(시작 + 종료 경계) | 쌍 전체에 대한 하나의 범위 인덱스 — 겹침 조회와 "이 날짜에 유효했던 값" 조회에 사용합니다 |
하나의 데이터베이스는 둘 이상의 스키마를 동기화할 수 있습니다. 연결된 스키마 전반에서 이름이 같은 엔티티 유형은 데이터베이스 키를 기준으로 병합되어 동일한 테이블에 저장됩니다 — 각 스키마의 보강은 자신의 열만 업데이트하므로, 두 스키마로 보강된 회사는 두 열 집합을 모두 담은 하나의 행이 됩니다. 특정 스키마에만 있는 유형은 각자의 테이블을 추가할 뿐이며, 피드의 자동 마이그레이션 델타를 통해 전달됩니다 — 다시 다운로드할 필요가 없습니다.
스키마를 연결하면 비교 단계에서 어떤 테이블이 병합되는지(키와 추가된 열 포함)와 어떤 것이 새로운지를 정확히 보여줍니다. 테이블을 공유하는 스키마는 해당 테이블의 기존 데이터베이스 키를 채택하며, 이는 검토를 위해 표시됩니다. 스키마 간에 공유되는 것이 없으면 대신 전용 데이터베이스를 제안합니다. 스키마 연결을 해제해도 데이터베이스는 절대 건드리지 않으며, 동기화된 테이블은 그대로 유지됩니다.
스키마 연결을 해제하거나 동기화를 삭제하면 우리 쪽에 두 가지가 남습니다: 더 이상 아무것도 기록하지 않는 저장된 엔티티 상태와, 스키마가 지닌 데이터베이스 속성(database key, 열 유형, 인덱스, 소유권)입니다. 두 확인 모두 이를 제거할 것을 제안하며, 데이터베이스가 전혀 남지 않은 스키마에 한해서만 그렇습니다 — 다른 곳에서 여전히 동기화되는 스키마는 모든 것을 유지합니다. 스키마 자체, 강화 레코드, 비용은 절대 영향받지 않습니다.
연결된 스키마에는 게시된 계약이 있습니다: 이는 보강과 데이터베이스가 실제로 사용하는 버전입니다. 스키마를 편집하면 작업 사본만 변경됩니다 — 표현 변경은 자동으로 반영되지만, 구조적 변경(새 필드, 유형 또는 키 변경)은 게시를 누를 때까지 대기합니다. 게시하면 정확한 영향을 미리 보고 적절한 마이그레이션을 델타 피드로 전송합니다: 새 열은 ALTER TABLE 델타로 도착하며, 더 큰 변경(새 데이터베이스 키, 유형 변경)은 사용자의 데이터베이스에 대해 보호된 마이그레이션으로 실행됩니다 — 데이터가 이를 차단하면(키 값 누락 또는 중복), 피드가 정확한 문제와 함께 일시 중지되고 문제를 해결하면 자동으로 재시도합니다.
게시는 데이터베이스의 Model 탭에 있습니다(스키마가 연결되어 있는 동안 Workflow Editor에 해당 위치를 가리키는 배너가 표시됩니다). 게시하기 전에 양쪽을 모두 보여줍니다: 오늘 데이터베이스가 사용 중인 계약과, 작업 사본이 변경할 모든 내용의 diff입니다. 편집이 마음에 들지 않으시나요? 게시된 버전으로 되돌리기가 계약을 원상 복구합니다 — 실행 취소가 가능하며, 따로 보관해 둔 초안은 24시간 동안 복원할 수 있습니다.
연결이 해제된 동안 편집된 스키마를 다시 연결하는 것도 같은 방식으로 작동합니다: 동기화는 데이터베이스가 이미 가지고 있는 것을 기억하고 차이점만 전송하며, 그 사이에 기록된 행에 대해서는 스냅샷 갱신을 함께 전송합니다. 수동 DROP은 절대 필요 없습니다.
동일한 보장은 저희 자체 업그레이드에도 적용됩니다. 새 릴리스에서 schema가 테이블에 매핑되는 방식이 개선되면 동기화가 자동으로 마이그레이션됩니다. 추가되는 변경 사항은 피드에 자동으로 반영됩니다. 업그레이드가 이미 보유한 테이블의 구조를 변경하는 경우, 저희는 통보 없이 데이터를 건드리지 않습니다. 전송이 일시 중지되고 Database Sync 페이지에서 무엇이 먼저 변경되는지 정확히 보여주며 적용을 요청합니다.
다국어 보강도 여기서 일급으로 지원됩니다: 현지화된 값은 보강의 모든 언어를 담은 JSONB 열로 도착합니다 — {"en": "Headache", "fr": "Céphalée"} — 따라서 하나의 데이터베이스가 모든 로케일을 한 번에 처리합니다. 쿼리에서 바로 언어를 선택할 수 있으며(name->>'fr'), JSON 델타 페이로드도 동일한 언어 키 객체를 담습니다.
모든 데이터베이스는 등록 시 한 가지 질문에 답합니다. 보강 결과에 누락, 즉 널을 허용하지 않는 필드가 채워지지 않은 상태로 돌아왔을 때 무엇을 기록할까요? 세 가지 답이 하나의 단계를 이룹니다. 아무것도 기록하지 않음: 중첩 객체 내부를 포함해 어디든 누락이 하나라도 있으면 엔터티가 거부됩니다. 불완전한 하위 항목을 제외한 엔터티(기본값): 엔터티 자체의 행은 완전해야 하지만, 문제가 있는 하위 항목은 보강 전체를 무산시키는 대신 건너뛰고 보고합니다. 전부 기록: 누락은 NULL로 기록되고 아무것도 거부되지 않습니다 — 하지만 엔터티 상태는 마지막 쓰기 우선이어서 가장 최근 보강이 곧 해당 행이므로, 이후의 부분적인 실행이 앞서 채워진 값을 지웁니다. 엄격한 두 단계는 바로 이 삭제를 막기 위해 존재합니다.
게이트를 통과하지 못한 보강 결과도 레코드로 저장되며 record.created 웹훅도 그대로 발생합니다. 이때 database.saved는 false로 설정되고 어떤 필수 필드가 누락되었는지 정확히 알려주므로, 불완전한 데이터가 조용히 사라지는 일은 없습니다. 누락된 각 필드에는 모델이 값을 알 수 없다고 명시했는지, 아니면 단순히 빠뜨렸는지도 표시됩니다. 전자는 더 강력한 모델이나 웹 검색, 원본 문서가 필요하다는 뜻이고, 후자는 스키마나 입력을 점검해야 한다는 뜻입니다. 데이터베이스 키 필드만은 항상 필수이며, 키 값이 없는 보강은 등급과 관계없이 거부됩니다.
엄격한 단계에서는 체크박스 하나로 동일한 계약을 사용자의 데이터베이스에도 반영하여, 항상 존재하는 모든 필드를 NOT NULL 컬럼으로 만듭니다. 가장 엄격한 단계에서는 필수 참조의 외래 키에도 제약이 적용되어 허용된 행은 이를 빠뜨릴 수 없습니다. 불완전한 하위 항목 건너뛰기에서는 참조 컬럼이 의도적으로 널을 허용합니다. 자체 값이 누락된 목록 항목은 제거되고, 대상이 불완전한 공유 일대일 참조(개장 연도를 아무도 모르는 경기장)는 분리됩니다 — 해당 대상은 기록되지도 갱신되지도 않고 저장된 행은 그쪽으로 아무것도 연결하지 않으므로, 바로 그 외래 키 컬럼에 NULL이 기록됩니다. 두 경우 모두 보강 응답에 보고되며, 최상위 필드의 누락은 항상 거부됩니다. 첫 동기화 이후에 정책을 변경해도 작업이 헛되지 않습니다. 변경은 피드에 보호된 마이그레이션으로 반영되어, 데이터베이스에 이미 저장된 행을 기준으로 검증됩니다.
두 번째 관문은 중복된 식별 정보를 잡아냅니다. 같은 목록의 두 항목이 같은 데이터베이스 키로 해석되면 — 모델이 서로 다른 두 회사에 하나의 id를 지어냈거나, 키가 둘을 구분하지 못하는 경우 — 행은 하나만 존재할 수 있으므로 마지막 항목이 기록되고 앞선 항목들은 버려집니다. 다른 모든 곳과 동일한 마지막 쓰기 우선 규칙입니다. 각 충돌은 두 항목의 식별 값 및 판정과 함께 보고됩니다. 중복은 같은 값을 반복한 것이므로 잃은 것이 없고, 충돌로 버려진 항목은 명시된 값을 잃습니다. 모델이 하나의 대상을 부정확한 값으로 반복했거나, 서로 다른 대상이어서 키에 구분 속성(지역, 연도, 버전)이 필요한 경우입니다. 이 목록은 레코드에 보관되므로, 부분 쓰기라도 응답이 사라진 뒤 한참 후까지 무엇을 잃었는지 알려줍니다.
다시 enrichment을 실행하기 전에 알아두어야 할 점이 하나 있습니다. 상위 항목에 속한 목록의 경우, 가장 최근 enrichment의 목록이 곧 그 목록입니다. 최신 응답이 다시 포함하지 않은 하위 행은 데이터베이스에서 삭제되며, 이것이 실제 삭제가 사용자에게 반영되는 방식입니다. 응답은 이를 보고하지 않습니다. 이는 model이 열거하기보다 기억해 내는 목록일 때 중요합니다. 어떤 원소의 동위원소나 어떤 사람의 수상 이력을 두 번 요청하면 두 번째 응답이 더 짧아질 수 있으며, 그 결과 실제로 존재하던 행이 제거됩니다. 모든 실행의 합집합이 필요하다면 별도로 자체 기록을 보관하세요.
보강 결과는 연결된 데이터베이스로 자동 전송됩니다. 그 외의 모든 경우 — 스키마를 수정하기 전에 게이트가 거부한 결과, 의도적으로 제외한 실행, 먼저 검토하거나 수정하려는 출력 — 은 레코드를 데이터베이스로 전송하는 과정을 거칩니다. 기록 페이지에서 선택하거나, 워크플로에서 API를 호출하세요.
왕복 처리. database sync를 끈 상태로 보강한 뒤, 자체 워크플로에서 결과를 변형하거나 승인하고 전송하세요. 전송한 내용은 스키마의 게시된 계약에 따라 다시 검증되며, 보강과 동일한 승인 게이트를 거칩니다 — 주입은 보강이 기록할 수 없는 값을 결코 기록할 수 없습니다.
알아 두면 좋은 두 가지가 있습니다. 레코드를 변경 없이 전송하면 해당 레코드 아래에 저장됩니다. 수정된 출력을 전송하면 원본을 가리키는 새 레코드가 생성되는데, 레코드는 감사 추적이기 때문입니다: 레코드를 인용하는 데이터 아래에서 절대 바뀌지 않으므로, 데이터베이스에 저장된 내용은 언제나 정확히 그 값을 담은 레코드로 추적할 수 있습니다. 또한 검증에는 현재 시점의 계약이 사용됩니다 — 레코드가 생성된 이후 스키마가 변경되었다면 전송하기 전에 기록 페이지에서 이를 표시해 줍니다.
기록 페이지에서는 레코드별로 데이터베이스 도달 여부도 확인할 수 있습니다: 전송됨, 부분 전송됨, 또는 사유와 함께 거부됨. 웹 앱, API, MCP, n8n, Make에서 이용할 수 있습니다.
피드는 데이터베이스별로 엄격한 FIFO 큐입니다. 윈도우를 가져오고(선택적으로 리스를 설정하면 중단된 워커의 배치가 더 새로운 항목보다 먼저 재전송됩니다), 적용한 뒤, 확인 응답합니다. 웹훅 알림은 디바운스됩니다 — 새 델타가 생길 때마다 대기 시간 타이머가 초기화되어 한꺼번에 몰린 보강이 한 번만 통지되며, 설정 가능한 최대 지연 시간이 대기 시간을 제한하고, 가져오기 페이지가 가득 차면 즉시 발송됩니다. 두 가지 정리 옵션으로 Entity Enricher가 보관하는 데이터를 제어합니다. 확인 응답 시 전달된 델타 사본을 삭제하는 옵션과, 데이터 최소화를 위해 스키마에 연결된 모든 데이터베이스가 수신한 후 엔터티 상태 자체를 삭제하는 옵션입니다. 각 옵션에는 일 단위 지연 시간을 선택적으로 지정할 수 있습니다. 전달된 사본은 확인 응답 후 그 기간만큼 유지되고(재전송 기간), 전달된 엔터티는 그 기간 동안 업데이트가 없을 때까지 보관되며, 매시간 실행되는 정리 작업이 만료된 항목을 삭제합니다. 상태 정리는 최소화이지 완전 삭제가 아닙니다. 보강 레코드는 직접 삭제하기 전까지 남아 있으며, 정리된 엔터티에 대해서는 보강 간 병합이 비활성화됩니다.
테이블별 체크섬 엔드포인트를 통해 아무것도 다시 다운로드하지 않고도 언제든지 복제본이 수렴했는지 확인할 수 있습니다.
모든 기능은 앱 한곳에 모여 있습니다 — 사이드바에서 History 바로 아래에 있는 Database Sync입니다. 여기서 스키마에 데이터베이스를 등록하고(database key 검토 포함), 스키마를 연결하거나 해제하고, 연결된 스키마의 보강 피드를 스위치로 일시 중지하고(다시 활성화할 때까지 새 데이터나 알림이 전달되지 않습니다 — 스키마 게시는 계속 DDL을 전송하며, 일시 중지 중에 실행된 보강은 스냅샷 재수집을 통해서만 복제본에 반영됩니다), 옵션을 편집하고, 웹훅 엔드포인트를 확인하고 서명 키를 표시하고, 스냅샷을 내려받고, 현재 엔티티 상태를 살펴보고, 대기 중인 델타 큐를 확인하고(읽기 전용이며 워크플로의 커서는 변경되지 않습니다), 생성된 테이블과 그 키 및 정션을 보여주는 엔티티 관계 다이어그램을 볼 수 있습니다. 여러 데이터베이스를 사용하는 database sync에서는 다이어그램을 한 스키마에 집중할 수 있습니다. 다른 스키마가 공급하는 테이블·열·링크는 회색으로 흐려지지만 자리에 그대로 남아 있어, 각 스키마가 공유 테이블에 무엇을 기여하는지 정확히 확인할 수 있습니다.
여러 데이터베이스가 같은 머신에 놓이는 경우, Sync hosts 툴바 버튼을 사용하면 데이터베이스마다 페어링 절차를 거칠 필요가 없습니다. 해당 머신을 한 번만 페어링한 뒤 등록 항목을 할당하면 됩니다. 호스트가 각 항목을 넘겨받아 물리적 데이터베이스가 없으면 생성하고 동기화를 시작합니다. 따라서 데이터베이스 등록은 서버의 터미널 세션이 아니라 이 화면에서 내리는 결정이 됩니다. 페어링은 Entity Enricher 서버 단위로 이루어지므로, 한 머신이 여러 인스턴스를 나란히 서비스할 수 있습니다.
데이터베이스가 거부하는 구문(대개 새 고유 인덱스에 걸리는 기존 중복이 원인입니다)이 있어도 뒤따르는 큐가 멈추지 않습니다. 해당 보강의 배치만 격리되고 피드는 계속 흐르며, 그 배치는 데이터베이스가 거부한 구문과 함께 격리 탭에 표시됩니다. 원인을 해결한 뒤 재주입하면 오래된 구문을 다시 실행하는 대신 엔터티를 현재 상태에서 다시 투영합니다. 또는 삭제할 수도 있습니다.
GET /api/databases//changes?since=…&format=sql 그다음 POST /api/databases//ack.Supabase를 사용하시나요? Supabase MCP 비교에서 EE의 관계 및 동기화 규칙이 제품 카탈로그를 어떻게 보호하는지 JSON과 간단한 테이블 다이어그램으로 확인하세요.
동기화 과정에서 어떤 것도 데이터베이스 서버 위에서 실행되지 않습니다 — 위의 모든 경로는 사용자가 제공하는 DSN에 연결하는 아웃바운드 소비자입니다. Azure Database for PostgreSQL, OVHcloud, AWS RDS, Supabase 또는 그 밖의 관리형 인스턴스도 자체 호스팅 인스턴스와 정확히 동일하게 동작합니다: 소비자를 클라우드 DSN으로 향하게 하고(관리형 제공자는 보통 TLS를 강제하므로 sslmode=require를 추가하세요) 적용하면 됩니다.
--dsn을 관리형 인스턴스로 향하게 한 노트북, 소형 VM 또는 컨테이너(Azure Container Apps, Docker 사이드카…)만 있으면 충분합니다.delta_available 웹훅이 Azure Function / AWS Lambda / OVHcloud 함수를 깨워 REST 피드를 가져오고 SQL을 실행하며 확인 응답합니다.두 가지 규칙이 직접 만든 소비자를 안전하게 유지합니다: 각 배치의 명령문을 순서대로, 하나의 트랜잭션 안에서 실행하고, 커밋 이후에만 확인 응답하세요. 델타는 멱등적이고 리비전으로 보호되므로, 확인 응답 전에 크래시가 발생하면 단순히 배치가 재전송되고 재적용이 수렴합니다.
데이터베이스는 유료 플랜에서 사용할 수 있습니다(등록 가능한 개수는 플랜에 따라 정해집니다). 최초 지원 방언은 PostgreSQL이며, 각 데이터베이스는 자체 방언을 선언합니다. MySQL / MariaDB, SQL Server, Oracle은 지원 예정입니다.