SQL/PGQ 프로퍼티 그래프

이 문서는 자라는 중인 질문입니다. 아직 증거를 모으고 있으며, 내용이 바뀔 수 있습니다.

한 줄로 말하면

SQL/PGQ 프로퍼티 그래프는 기존 관계형 테이블 위에 “이 행은 정점, 이 관계는 간선”이라는 읽기 방식을 선언하고, 고정된 연결 패턴을 SQL 안에서 질의하게 해 주는 구조야.¹

비유로 이해하기

이미 지어진 도시 위에 새 지도를 한 장 겹쳐 놓는다고 생각하면 쉬워. 건물과 도로를 새로 옮기지는 않아. 대신 어떤 건물을 장소로 보고, 어떤 길을 연결로 볼지 지도 위에 표시해.

관계형 데이터베이스에서도 비슷한 일이 일어나. 테이블과 행은 그대로 남고, CREATE PROPERTY GRAPH 선언이 어느 테이블을 정점으로 읽고 어느 테이블을 간선으로 읽을지 정해. 여기까지가 비유야. 실제로는 지도 그림이 아니라, SQL 질의가 읽을 수 있는 이름 있는 선언 객체에 가깝다.¹

정확한 정의

SQL/PGQ에서 프로퍼티 그래프는 기존 테이블을 정점과 간선으로 해석하는 선언이야. VERTEX TABLES는 행을 정점으로 읽을 테이블을 정하고, EDGE TABLES는 행을 연결 관계로 읽을 테이블을 정한다. 정점에는 식별자인 KEY, 패턴에서 부를 LABEL, 질의에 노출할 PROPERTIES를 둘 수 있어. 간선은 출발 정점과 도착 정점을 지정한다.¹

중요한 점은 데이터가 복사되지 않는다는 거야. 행은 원래 테이블에 남고, 그래프 선언은 그 관계를 다른 문법으로 읽는 방법을 붙인다. 그래서 그래프 질의도 결과를 테이블처럼 돌려준다. GRAPH_TABLE(...) 안에 MATCH 패턴을 쓰고, 바깥의 SELECT는 그 결과를 일반 테이블처럼 다룰 수 있어.¹

flowchart TD
    A["기존 관계형 테이블"] --> B["CREATE PROPERTY GRAPH 선언"]
    B --> C["정점 테이블과 간선 테이블"]
    C --> D["MATCH 패턴"]
    D --> E["관계형 조인으로 실행"]
    E --> F["테이블 형태의 결과"]

이 그림에서 핵심은 마지막 두 칸이야. MATCH는 별도 그래프 실행 엔진으로 빠져나가는 문법이 아니라, 기반 테이블을 대상으로 한 관계형 조인으로 실행된다. 그래서 느린 그래프 질의를 만났을 때도 기존 옵티마이저, 인덱스, 통계를 보고 일반 조인처럼 분석할 수 있다.¹

왜 중요한가

SQL/PGQ가 풀어 주는 문제는 “관계형 데이터베이스가 그래프가 된다”가 아니야. 이미 외래 키와 조인으로 표현하던 연결을, 사람이 관계 모양으로 읽기 쉽게 쓰게 해 주는 데 가까워.

예를 들어 여러 테이블을 계속 자기 조인하면서 “A에서 B를 거쳐 C로 간다”는 구조를 찾는 질의는 SQL만 보면 의도가 흐려질 수 있어. 프로퍼티 그래프 문법은 그 연결 모양을 MATCH 패턴으로 드러낸다. 구조가 고정돼 있고 어느 관계를 따라갈지 이미 안다면, 같은 질의가 더 읽기 쉬워질 수 있다.¹

또 하나의 가치는 문서화야. 어떤 테이블이 엔터티이고, 어떤 테이블이 관계이고, 어떤 열을 그래프 질의에 노출할지 선언으로 남기면 스키마를 다른 각도에서 읽을 수 있다. SQLite STRICT 테이블이 값의 타입 경계를 테이블 선언으로 드러내는 장치라면, SQL/PGQ 프로퍼티 그래프는 테이블 사이의 연결 경계를 선언으로 드러내는 장치라고 볼 수 있어.

실제 예시

차원 테이블은 보통 정점으로 읽기 쉽다. 운전자, 팀, 서킷처럼 안정적인 기본 키와 속성을 가진 테이블은 각각 하나의 대상 목록이기 때문이야. 다대다 브리지 테이블처럼 두 대상을 연결하는 것이 본래 역할인 테이블은 간선으로 읽기 쉽다.¹

반대로 팩트 테이블은 조심해야 해. 어떤 결과 행이 운전자, 경기, 팀을 동시에 가리키고 자기 속성도 갖고 있다면, 그 행 전체를 하나의 간선으로 밀어 넣기 어렵다. SQL/PGQ의 간선은 출발점 하나와 도착점 하나를 가진 관계라서 그래. 이럴 때는 팩트 행 자체를 이벤트 정점으로 두고, 그 이벤트 정점에서 운전자·경기·팀으로 좁은 간선을 뻗게 모델링하는 편이 더 자연스럽다.¹

한 테이블을 한 역할로만 써야 하는 것도 아니야. 같은 기반 테이블을 서로 다른 별칭으로 정점과 여러 간선에 동시에 선언할 수 있다. 이미 있는 기본 키와 외래 키를 쓰면 별도의 그래프용 연결 테이블을 새로 저장하지 않아도 된다.¹

헷갈리지 말아야 할 점

그래프 데이터베이스로 옮긴다는 뜻이 아니야. 여기서 핵심은 기존 테이블 위의 선언과 질의 문법이지, 데이터를 다른 저장소로 복사하는 일이 아니다.
키는 자동으로 프로퍼티가 되지 않아. 정점 식별자로 쓴 열을 필터링하거나 반환하려면 PROPERTIES에 따로 노출해야 한다.¹
동명 프로퍼티의 타입 충돌을 조심해야 해. 여러 테이블에 같은 이름의 열이 있고 타입이 다르면 그래프 전체의 프로퍼티 이름 규칙과 부딪힐 수 있다. 필요한 열만 명시적으로 노출하는 방식이 방어선이 된다.¹
Postgres 19 기준으로 열린 길이의 탐색에는 맞지 않아. 최단 경로, 몇 홉 안의 도달성, 깊이를 모르는 연결 탐색은 가변 길이 경로가 필요하다. 이 경우에는 프로퍼티 그래프 문법보다 재귀 CTE나 다른 그래프 처리 방식이 맞을 수 있다.¹
PageRank나 중심성 계산 같은 그래프 알고리듬과도 다르다. SQL/PGQ의 강점은 알고 있는 패턴을 읽기 쉽게 질의하는 쪽이지, 그래프 전체의 구조적 중요도를 계산하는 쪽이 아니다.¹

남은 질문들

PostgreSQL 19의 실제 구현은 SQL/PGQ 표준 중 어디까지 지원하고, 어떤 문법을 아직 지원하지 않을까?
MATCH가 관계형 조인으로 바뀔 때, 기존 조인 SQL과 실행 계획이 얼마나 비슷하게 나오고 어디서 달라질까?
복잡한 스키마에서 어떤 팩트 테이블은 이벤트 정점으로, 어떤 브리지 테이블은 간선으로 두는 기준을 어떻게 정해야 할까?
고정된 패턴 탐색은 SQL/PGQ로 두고, 열린 길이의 탐색은 재귀 CTE나 그래프 엔진으로 넘기는 경계는 어디일까?

GeekNews, 「Postgres 19의 프로퍼티 그래프 이해하기」 원문. ↩︎ ↩︎² ↩︎³ ↩︎⁴ ↩︎⁵ ↩︎⁶ ↩︎⁷ ↩︎⁸ ↩︎⁹ ↩︎¹⁰ ↩︎¹¹ ↩︎¹² ↩︎¹³

🥚

Explorer

Recent Notes

에이전트 유통

연결 풀러 프로세스 플릿

성과 기반 SaaS 과금