Postgres 19 프로퍼티 그래프, 조인을 MATCH로 읽는 법

Postgres 19 프로퍼티 그래프, 조인을 MATCH로 읽는 법

Postgres 19 프로퍼티 그래프 썸네일

Postgres 19에는 기존 테이블을 정점과 간선으로 선언하고 관계 패턴을 `MATCH`로 찾는 프로퍼티 그래프 기능이 들어와요. 데이터를 다른 시스템으로 옮기지 않고도 익숙한 관계형 스키마를 그래프 관점으로 조회할 수 있어요. 다만 정해진 길이의 관계 탐색에 초점이 맞춰져 있어 사용 범위를 먼저 구분해야 해요. 1 2

핵심 요약

구분	핵심	왜 볼만한가요
저장 구조	기존 테이블 위에 그래프 선언을 만들어요	데이터 복사와 별도 그래프 저장소가 필요 없어요
질의 방식	`GRAPH_TABLE` 안에서 `MATCH` 패턴을 써요	여러 조인의 관계 방향을 한눈에 읽기 쉬워요
실행 방식	그래프 패턴이 관계형 조인으로 바뀌어요	기존 인덱스, 통계, 옵티마이저를 그대로 활용해요
모델링	차원은 정점, 조인 테이블은 간선으로 대응하기 쉬워요	팩트 테이블은 이벤트 정점으로 보는 편이 자연스러워요
제약	가변 길이 경로를 아직 지원하지 않아요	최단 경로나 임의 깊이 탐색에는 재귀 CTE가 필요해요

1. 그래프 문법을 더했지만 실행 엔진은 그대로예요

`CREATE PROPERTY GRAPH`는 새 저장소를 만드는 명령이 아니에요. 기존 테이블의 어떤 행을 정점으로 읽고, 어떤 관계를 간선으로 읽을지 이름 붙여 선언해요. 원본 행은 테이블에 남고 그래프용 복사본도 생기지 않아요. 2

질의는 `GRAPH_TABLE(...)` 안에 `MATCH` 패턴을 넣는 방식이에요. 예를 들어 드라이버에서 경기 결과를 거쳐 레이스로 이어지는 관계를 방향이 있는 패턴으로 표현할 수 있어요. 반환할 열은 `COLUMNS`에서 고르고, 바깥쪽 `SELECT`에서는 결과를 일반 테이블처럼 다뤄요.

728x90

실행 단계에서는 이 패턴이 기반 테이블의 조인으로 변환돼요. 원문의 Formula 1 예제에서 `EXPLAIN`을 확인하자 여러 해시 조인이 나타났어요. 별도 그래프 엔진이 순회를 처리하는 구조가 아니어서, 성능이 느리면 일반 조인과 같은 방식으로 실행 계획과 통계, 인덱스를 점검하면 돼요.

키와 프로퍼티는 따로 지정해야 해요

정점의 `KEY`로 지정한 열이 자동으로 조회 가능한 프로퍼티가 되지는 않아요. ID를 필터 조건이나 반환값으로 쓰려면 `PROPERTIES`에도 해당 열을 넣어야 해요. `PROPERTIES`를 생략해 모든 열을 노출할 때는 서로 다른 테이블의 동명 열 타입이 충돌할 수도 있어요. 필요한 열만 명시하면 노출 범위와 타입 충돌을 함께 관리할 수 있어요.

팩트 테이블은 이벤트 정점으로 읽을 수 있어요

차원 테이블은 안정적인 식별자와 속성을 가진 엔티티라 정점으로 옮기기 쉬워요. 두 외래 키를 연결하는 순수 조인 테이블은 행 자체가 관계이므로 간선에 잘 맞아요.

여러 외래 키와 자체 속성을 함께 가진 팩트 테이블은 판단이 달라져요. 경기 결과 행에는 드라이버, 레이스, 팀을 가리키는 외래 키와 순위, 점수 같은 속성이 함께 있어요. SQL/PGQ의 간선은 출발점과 도착점이 하나씩인 이항관계라서 이 행 전체를 간선 하나로 표현하기 어려워요. 팩트 행을 이벤트 정점으로 두고 외부 엔티티로 뻗는 좁은 간선을 선언하면 속성을 보존하면서 관계를 탐색할 수 있어요.

Postgres 19에서는 같은 기반 테이블을 정점과 간선 양쪽에 서로 다른 별칭으로 선언할 수도 있어요. 경기 결과 테이블을 이벤트 정점으로 쓰면서 `result → driver`, `result → race`, `result → constructor` 간선의 원천으로 다시 사용할 수 있어요. 별도의 간선 테이블 세 개를 저장하지 않아도 기존 기본 키와 외래 키를 재사용할 수 있다는 뜻이에요.

고정된 관계를 찾을 때 잘 맞아요

관계의 모양과 길이를 미리 아는 질의라면 `MATCH`가 여러 자기 조인보다 읽기 쉬울 수 있어요. 특정 드라이버가 어느 팀에서 뛰었는지 찾거나, 같은 레이스에 참여한 경쟁자를 찾거나, 구조와 속성 조건을 함께 거르는 작업이 여기에 들어가요.

반대로 Postgres 19의 프로퍼티 그래프는 가변 길이 경로 수량자를 지원하지 않아요. 두 정점 사이의 최단 경로, N 홉 이내 도달 가능한 대상, 깊이를 알 수 없는 연결 관계는 이 문법만으로 처리할 수 없어요. 이런 탐색에는 기반 테이블을 대상으로 재귀 CTE를 써야 해요. PageRank나 중심성, 커뮤니티 탐지 같은 그래프 알고리즘도 고정 패턴 매칭의 범위를 벗어나요.

왜 중요한가요

Postgres를 이미 운영하는 팀이라면 그래프 형태의 질문이 생겼다는 이유만으로 데이터를 복제하고 별도 그래프 데이터베이스를 운영할 필요가 줄어들 수 있어요. 관계가 고정된 조회는 기존 스키마와 운영 도구를 유지한 채 더 읽기 좋은 문법으로 표현할 수 있어요. `EXPLAIN`, 인덱스, 통계처럼 익숙한 성능 점검 방식도 그대로 이어져요. 2

도입 판단은 질의의 깊이에서 갈려요. 필요한 경로가 정해져 있고 유한하면 프로퍼티 그래프를 시험해 볼 만해요. 경로 자체를 발견하거나 임의 깊이를 순회해야 한다면 재귀 SQL이나 전문 그래프 시스템이 더 알맞을 수 있어요. 실제 스키마와 데이터 분포에서 실행 계획을 비교한 뒤 선택하는 편이 안전해요.

참고 자료

1. Postgres 19의 프로퍼티 그래프 이해하기 — GeekNews
2. Understanding Postgres 19 Property Graphs — neovintage.org