Postgres 19는 기존 테이블에 그래프 문법을 겹쳐 놓는다

Postgres 19의 SQL/PGQ는 기존 테이블을 정점과 간선으로 읽는 방법을 선언하고, 그 위에 그래프 모양의 질문을 쓸 수 있게 해. 데이터를 복사하거나 별도 그래프 실행 엔진을 만들지 않고도 관계형 스키마를 다른 모양으로 질의하는 방식이야.¹

테이블에 지도를 겹쳐 놓는 방식

관계형 스키마의 각 행은 잠재적인 정점이고, 외래 키는 다른 행을 가리키는 잠재적인 간선이야. 운전자·팀·서킷처럼 안정적인 기본 키와 속성을 가진 차원 테이블은 정점으로 읽기 쉽고, 두 대상을 연결하는 순수 조인 테이블은 간선으로 대응하기 좋지.¹

CREATE PROPERTY GRAPH는 이 대응을 이름 있는 선언으로 만든다. VERTEX TABLES에는 정점으로 읽을 테이블을, EDGE TABLES에는 연결 관계로 읽을 테이블을 적는다. 정점에는 식별자인 KEY, 패턴에서 부를 LABEL, 질의에 노출할 PROPERTIES를 지정하고, 간선에는 출발점과 도착점을 지정해.¹

중요한 건 데이터가 움직이지 않는다는 점이야. 행은 원래 테이블에 남고, 선언은 외래 키 구조를 그래프로 읽는 방법만 정한다. 하나의 테이블을 서로 다른 별칭으로 정점과 여러 간선에 함께 선언할 수도 있어서, 기존 외래 키를 연결하기 위한 별도 테이블을 새로 저장하지 않아도 돼.¹

조인을 패턴으로 읽는다

그래프 질의는 GRAPH_TABLE(...) 안에 MATCH 패턴을 쓰는 식이야. 예를 들어 아래 패턴은 운전자에서 결과를 거쳐 경주로 이어지는 관계를 나타내.

MATCH (d IS driver)<-[IS of_driver]-(res IS result)-[IS in_race]->(ra IS race)

COLUMNS 절로 바깥에 반환할 열을 정하고, 바깥쪽 SELECT에서는 그 결과를 일반 테이블처럼 조회해. 방향과 레이블이 패턴 안에 드러나서, 여러 번의 조인을 직접 나열하는 것보다 관계의 모양을 읽기 쉬울 수 있어.¹

그렇다고 Postgres 안에 별도의 그래프 순회 엔진이 붙는 건 아니야. MATCH는 기반 테이블을 대상으로 한 관계형 조인으로 컴파일돼. 자료의 Formula 1 예시에서 EXPLAIN을 실행하면 네 개의 해시 조인이 나타나고, 기존 조인과 마찬가지로 옵티마이저·인덱스·통계를 사용해. 그래프 질의가 느릴 때 살펴볼 대상도 결국 일반 조인이 느릴 때와 크게 다르지 않다는 뜻이야.¹

여기서 PGQ 프로퍼티 그래프의 핵심이 선명해져. 새 그래프 저장소를 만드는 기능이라기보다, 이미 있는 관계를 다른 모양으로 선언하고 읽는 기능에 가까워.

팩트 테이블은 간선보다 이벤트에 가깝다

여러 외래 키와 자기 속성을 가진 팩트 테이블은 단순한 간선으로 만들기 어렵다. 예를 들어 results의 한 행이 운전자·경주·팀을 가리키면서 순위와 점수도 갖고 있다면, 출발점 하나와 도착점 하나를 전제로 하는 간선에 모든 의미를 넣을 수 없지.¹

이럴 때는 results 행 자체를 이벤트를 담은 정점으로 두고, 그 정점에서 운전자·경주·팀으로 가는 좁은 간선을 선언하는 모델이 더 자연스럽다. 같은 테이블을 result 정점으로 읽으면서 driver, race, constructor로 향하는 서로 다른 간선 별칭으로 재사용할 수 있다는 점이 이 모델을 받쳐 줘.¹

다만 키와 프로퍼티를 혼동하면 안 돼. 정점의 KEY로 지정한 열은 자동으로 질의 가능한 프로퍼티가 되지 않는다. ID를 필터링하거나 결과로 반환하려면 PROPERTIES 목록에 따로 넣어야 해. 여러 테이블에 같은 이름의 열이 있고 타입까지 다르면 프로퍼티 충돌이 생길 수 있으니, 필요한 열만 명시하는 편이 안전해.¹

열린 경로까지 해결하지는 않는다

Postgres 19의 SQL/PGQ는 관계 구조를 미리 아는 고정된 패턴에 잘 맞아. 두 홉을 찾고 싶다면 MATCH에 두 개의 간선 패턴을 적으면 돼. 반대로 간선을 1~3회 따라가는 식의 요소 패턴 수량자나 임의 길이 경로는 지원하지 않아.¹

그래서 최단 경로, 몇 홉 안의 도달성, 깊이를 모르는 연결 탐색은 이 문법만으로 표현할 수 없다. 그런 문제는 기반 테이블에 재귀 CTE를 쓰는 영역으로 넘어가고, PageRank·중심성 계산 같은 그래프 알고리듬도 고정 패턴 질의와는 다른 문제로 남아.¹

다음에 볼 기준은 단순해. 관계의 모양을 알고 있고 기존 테이블 안에서 그 패턴을 읽고 싶다면 SQL/PGQ가 맞는지 직접 실행 계획과 성능을 확인해 볼 수 있어. 경로의 깊이 자체를 찾아야 한다면, 그래프라는 이름만 보고 MATCH에 억지로 맡기기보다 재귀 SQL이나 별도 처리 방식을 검토해야 해.

각주

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