온톨로지에 PostgreSQL과 Neo4j를 함께 쓰는 이유

2026년 8월 29일 기준, 데이터 책임자는 PostgreSQL을 원본, Neo4j를 투영으로 둡니다. 다만 양쪽에 직접 쓰면 안 됩니다.

관계 탐색이 필요하다고 모든 데이터를 그래프 DB로 옮길 이유는 없습니다. 반대로 행 저장만으로 멀티홉 관계를 매번 조립하면 질의 책임이 애플리케이션에 흩어집니다. 핵심은 쓰기 소유자와 재구축 원본을 하나로 고정하는 일입니다.

현재 문제에 따라 먼저 볼 저장소#

• 거래·원문·근거를 함께 기록한다면 PostgreSQL 쓰기를 봅니다.
• 객체 사이 경로를 반복 조회한다면 Neo4j 읽기를 봅니다.
• 두 저장소가 어긋났을 때 재구축 원본을 답할 수 있어야 합니다.

질문과 근거의 범위를 먼저 잡으려면 ERP 데이터 AI 에이전트 구축 기준부터 확인할 수 있습니다.

PostgreSQL과 Neo4j의 책임은 어떻게 나누나요?#

아래 표는 Ontokit C 자기표기 구현을 2026년 8월 29일 확인해 정리한 역할표입니다. 모든 온톨로지 시스템이 두 저장소를 써야 한다는 뜻은 아닙니다.

outbox가 두 저장소 사이 계약이 됩니다#

C 자기표기, 2026년 8월 29일 확인. Ontokit의 buildOutboxEvent는 연산, 집계 ID와 버전으로 멱등 키를 만들고 연산별 payload를 공통 스키마로 검증합니다. 노드와 엣지의 스냅샷을 outbox에 담아 워커가 Neo4j 투영을 갱신하도록 설계돼 있습니다.

동기화 워커는 노드를 먼저 반영한 뒤 엣지 끝점을 검사합니다. upsert에는 version 가드를 두고 실패 이벤트는 재시도 시각과 오류를 남깁니다. 전체 rebuild는 PostgreSQL을 스캔해 같은 Cypher 빌더로 그래프를 다시 만들고 노드·엣지 수 일치를 반환합니다.

실제 고객 운영의 동기화 지연, 처리량과 비용 절감은 미확인입니다. 구축 범위는 Ontokit 온톨로지 솔루션, 전환 검증은 ERP 데이터 이관 절차에서 이어서 볼 수 있습니다.

공식 문서는 투영과 변경 집합을 어떻게 설명하나요?#

B 공식 원문, 2026년 8월 29일 확인. PostgreSQL 문서는 logical publication을 테이블 변경 집합으로 설명합니다. publication은 스키마와 다르며 UPDATE·DELETE 전달에는 replica identity가 필요합니다. Ontokit은 이 기능을 쓴다고 주장하지 않습니다. PostgreSQL publication 문서에서 원문을 확인할 수 있습니다.

B 공식 근거, 2026년 8월 29일 확인. Neo4j GDS 공식 문서는 Cypher projection을 질의 문맥에서 메모리 그래프를 만드는 방식으로 설명합니다. 이는 분석용 메모리 projection의 정의이며 모든 Neo4j 저장 구조가 파생본이라는 뜻은 아닙니다. Neo4j Cypher projection 문서에서 범위를 확인할 수 있습니다.

함께 쓸 때 가장 자주 깨지는 가정#

애플리케이션이 두 저장소에 차례로 직접 쓰면 한쪽 성공 뒤 다른 쪽 실패를 한 트랜잭션으로 복구하기 어렵습니다. 원본 쓰기와 변경 이벤트를 같은 트랜잭션에 두고 그래프는 재처리 가능한 투영으로 제한해야 합니다.