Postgres 19 프로퍼티 그래프 이해하기: 관계형 데이터를 그래프처럼 조회하는 SQL/PGQ

Postgres 19에는 프로퍼티 그래프(Property Graph) 기능이 추가되면서, 기존 관계형 데이터를 별도의 그래프 데이터베이스로 옮기지 않고도 그래프 형태로 조회할 수 있게 되었습니다.

기존에는 여러 테이블을 조인(JOIN)하여 관계를 탐색해야 했다면, 이제는 MATCH 문법을 통해 "어떤 객체가 어떤 관계로 연결되어 있는가"를 그래프 패턴으로 직관적으로 표현할 수 있습니다.

무엇보다 중요한 점은 이 기능이 데이터를 새롭게 저장하거나 복사하는 것이 아니라, 기존 관계형 스키마를 그래프 관점으로 해석하는 선언적 기능이라는 것입니다. 따라서 기존 Postgres의 옵티마이저, 인덱스, 통계를 그대로 활용하면서 그래프 패턴 질의를 수행할 수 있습니다.

이번 글에서는 Postgres 19 프로퍼티 그래프의 개념부터 구성 방식, 활용 사례, 제약 사항까지 정리해보겠습니다.

반응형

---

Postgres 19 프로퍼티 그래프란?

Postgres 19의 프로퍼티 그래프는 기존 관계형 테이블을 다음과 같이 해석합니다.

• 테이블의 행(Row) → 정점(Vertex)
• 외래 키(Foreign Key) → 간선(Edge)

즉, 기존 데이터 구조를 그대로 유지하면서 그래프 형태로 조회할 수 있도록 해주는 기능입니다.

기존에는 다음과 같은 SQL을 작성해야 했다면

results
JOIN drivers
JOIN races
JOIN constructors

이제는 관계를 하나의 그래프 패턴으로 표현할 수 있습니다.

driver ← result → race

즉, JOIN을 직접 나열하는 대신 관계 자체를 표현하는 방식으로 SQL을 작성할 수 있습니다.

---

관계형 스키마를 그래프로 읽는 방식

관계형 데이터베이스는 원래부터 그래프적인 요소를 가지고 있습니다.

예를 들어 Formula 1 데이터에서는

• drivers
• constructors
• circuits

같은 차원(Dimension) 테이블은 독립적인 엔터티를 저장합니다.

반면

• results
• qualifying

같은 팩트(Fact) 테이블은 여러 엔터티를 연결하는 이벤트를 저장합니다.

관계를 그래프로 바라보면 다음과 같습니다.

• 차원 테이블의 행 → 정점
• 외래 키 → 간선

즉,

Driver
   │
Result
   │
Race

처럼 기존 관계형 모델을 그대로 그래프로 해석할 수 있습니다.

ER 다이어그램 역시 스키마 수준의 그래프이며, 실제 데이터(Row)는 인스턴스 수준의 그래프라고 볼 수 있습니다.

---

CREATE PROPERTY GRAPH란?

프로퍼티 그래프는 CREATE PROPERTY GRAPH 명령으로 생성합니다.

여기서 중요한 점은 새로운 데이터를 생성하는 것이 아니라 선언만 추가한다는 것입니다.

즉,

• 데이터를 복사하지 않음
• 기존 테이블 그대로 사용
• 기존 외래 키 그대로 사용

단순히

"이 테이블은 정점이다."

또는

"이 테이블은 간선이다."

라고 선언하는 수준입니다.

구성 요소는 크게 두 가지입니다.

Vertex Tables

정점으로 사용할 테이블을 정의합니다.

각 정점에는 다음 정보가 필요합니다.

• KEY
• LABEL
• PROPERTIES

KEY

정점을 식별하는 값입니다.

대부분 기본 키(PK)를 사용합니다.

LABEL

MATCH 문에서 사용하는 정점 이름입니다.

예를 들어

driver
race
constructor

같은 이름을 사용할 수 있습니다.

PROPERTIES

그래프 질의에서 사용할 컬럼입니다.

필요한 컬럼만 선택적으로 노출할 수 있습니다.

---

Edge Tables

간선으로 사용할 테이블입니다.

간선은 반드시

• SOURCE
• DESTINATION

을 지정해야 합니다.

즉,

Driver
    ↓
Result

처럼 출발 정점과 도착 정점을 정의합니다.

---

MATCH로 그래프 질의하기

그래프 질의는 GRAPH_TABLE() 내부에서 MATCH 문법을 사용합니다.

예를 들어

Driver
   ↓
Result
   ↓
Race

관계를 조회한다면

MATCH
(driver)<-(result)->(race)

처럼 표현할 수 있습니다.

이후 COLUMNS 절에서 반환할 컬럼을 지정하면 일반 SELECT 문처럼 사용할 수 있습니다.

복잡한 JOIN을 여러 번 작성하는 것보다 관계 구조를 훨씬 쉽게 이해할 수 있다는 것이 가장 큰 장점입니다.

---

내부적으로는 일반 JOIN으로 실행된다

MATCH는 그래프 전용 실행 엔진이 아닙니다.

실행 시에는 일반 SQL JOIN으로 변환됩니다.

즉,

MATCH

↓

JOIN

으로 컴파일됩니다.

따라서 실행 계획(EXPLAIN)을 확인하면 일반 JOIN과 동일한 형태가 나타납니다.

예를 들어

• Hash Join
• Nested Loop
• Index Scan

등 기존 Postgres 실행 계획을 그대로 사용합니다.

따라서

• 기존 옵티마이저
• 기존 인덱스
• 기존 통계

를 모두 그대로 활용할 수 있습니다.

그래프 질의가 느리다면 원인 역시 일반 JOIN이 느린 경우와 동일한 방식으로 분석하면 됩니다.

---

KEY와 PROPERTIES는 다르다

많이 헷갈리는 부분입니다.

KEY는 정점을 식별하기 위한 값입니다.

하지만 KEY로 지정했다고 해서 자동으로 조회 가능한 프로퍼티가 되지는 않습니다.

예를 들어

driver_id

를 KEY만 지정했다면

d.driver_id

로 조건을 작성할 수 없습니다.

조회에 사용하려면

PROPERTIES

목록에도 명시해야 합니다.

즉,

• KEY → 식별용
• PROPERTIES → 질의용

역할이 서로 다릅니다.

---

팩트 테이블은 정점으로 모델링하는 것이 적합한 이유

차원 테이블은 정점으로 사용하는 것이 자연스럽습니다.

예를 들어

• Driver
• Circuit
• Constructor

는 모두 독립적인 엔터티입니다.

반면

results

테이블은 조금 다릅니다.

results는

• Driver
• Race
• Constructor

세 개를 동시에 참조합니다.

또한

• grid
• position
• points
• status

같은 자체 데이터도 가지고 있습니다.

이런 경우에는 results를 간선으로 만들기보다 이벤트를 나타내는 정점(Vertex) 으로 모델링하는 것이 적합합니다.

즉,

Driver
      \
       Result
      /
Race

와 같은 허브(Hub) 구조를 만드는 방식입니다.

이 구조에서는 Result 자체가 하나의 분석 대상이 되며, 다양한 속성을 기준으로 필터링하거나 조회할 수 있습니다.

---

하나의 테이블을 정점과 간선으로 동시에 사용할 수 있다

Postgres 19의 특징 중 하나는 하나의 테이블을 여러 역할로 선언할 수 있다는 점입니다.

예를 들어

results

테이블 하나를

• Result 정점
• Driver 연결 간선
• Race 연결 간선
• Constructor 연결 간선

으로 동시에 선언할 수 있습니다.

이때 실제 데이터를 복사하지 않습니다.

별도의

• results_driver
• results_race
• results_constructor

테이블을 생성할 필요도 없습니다.

단순히 하나의 테이블을 여러 별칭으로 참조하는 방식입니다.

---

프로퍼티 타입 충돌에 주의해야 한다

PROPERTIES를 생략하면 모든 컬럼이 자동으로 프로퍼티가 됩니다.

이때 서로 다른 테이블에 같은 이름의 컬럼이 있지만 타입이 다르면 오류가 발생합니다.

예를 들어

number

컬럼이

• bigint
• double precision

으로 각각 존재한다면 타입 충돌이 발생합니다.

이 문제는 필요한 컬럼만 PROPERTIES에 명시하여 해결할 수 있습니다.

---

Postgres 19 프로퍼티 그래프의 한계

현재 가장 큰 제약은 가변 길이 경로(Variable Length Path)를 지원하지 않는다는 점입니다.

예를 들어 다음과 같은 질의는 지원되지 않습니다.

• 최단 경로 탐색
• N-Hop 탐색
• 도달 가능 노드 검색
• 깊이를 알 수 없는 연결 탐색

또한 다음과 같은 그래프 알고리즘도 대상이 아닙니다.

• PageRank
• 중심성(Centrality)
• 커뮤니티 탐지

이러한 작업은 재귀 CTE를 사용하거나 다른 그래프 분석 방식이 필요합니다.

즉, Postgres 19의 프로퍼티 그래프는 패턴 매칭 중심의 기능으로 이해하는 것이 적절합니다.

---

어떤 경우에 적합할까?

프로퍼티 그래프는 관계 구조를 미리 알고 있는 고정 길이 탐색에 적합합니다.

예를 들어 다음과 같은 질의가 대표적입니다.

• 특정 Driver가 어떤 Constructor에서 활동했는지 조회
• Driver → Result → Race 형태의 관계 탐색
• 구조와 속성을 함께 조건으로 검색
• 여러 번의 자기 조인을 하나의 MATCH 패턴으로 표현

반면 다음과 같은 문제에는 적합하지 않습니다.

• 최단 경로 찾기
• 임의 깊이의 연결 탐색
• PageRank와 같은 그래프 알고리즘 수행

이러한 작업은 재귀 CTE 등 다른 접근 방식이 필요합니다.

---

도입 전에 확인해야 할 사항

Postgres 19 프로퍼티 그래프는 별도의 그래프 데이터베이스를 구축하지 않고도 기존 관계형 데이터를 그래프 형태로 조회할 수 있게 해주는 기능입니다.

특히 다음과 같은 장점이 있습니다.

• 기존 데이터를 그대로 활용
• 데이터 복사 및 별도 저장 불필요
• 기존 옵티마이저와 인덱스 재사용
• 복잡한 JOIN을 직관적인 MATCH 패턴으로 표현
• 그래프 구조를 선언적으로 문서화 가능

다만 현재는 고정 길이 패턴 탐색에 초점이 맞춰져 있으며, 가변 길이 탐색이나 그래프 알고리즘은 지원하지 않습니다. 따라서 실제 도입 전에는 대상 업무가 고정된 관계 패턴 조회에 적합한지 검토하고, 필요한 성능이 나오는지 충분한 테스트를 수행하는 것이 중요합니다.

728x90

Postgres 19의 프로퍼티 그래프는 관계형 데이터베이스와 그래프 데이터베이스 사이의 간극을 줄여주는 기능입니다. 기존 스키마를 변경하거나 데이터를 별도로 관리하지 않아도 CREATE PROPERTY GRAPH와 MATCH를 활용해 그래프 관점의 질의를 수행할 수 있다는 점이 가장 큰 특징입니다.

특히 고정된 관계 구조를 탐색하는 업무에서는 복잡한 JOIN보다 높은 가독성을 제공하면서도 기존 Postgres의 실행 엔진과 성능 최적화 체계를 그대로 활용할 수 있습니다.

반면, 최단 경로 탐색이나 N-Hop 탐색처럼 경로의 길이가 정해져 있지 않은 그래프 분석에는 적합하지 않으므로, 활용 목적을 명확히 구분하여 적용하는 것이 중요합니다. 관계형 데이터 위에서 그래프 패턴 질의를 도입하려는 환경이라면, 별도의 그래프 데이터베이스를 검토하기 전에 Postgres 19의 프로퍼티 그래프 기능을 먼저 평가해볼 만한 선택지가 될 수 있습니다.

300x250

https://neovintage.org/posts/postgres-property-graphs/

Understanding Postgres 19 Property Graphs