목차
1. 복잡한 문서구조 어플리케이션 개발을 위한 PostgreSQL의 적합성
2. MySQL의 한계
3. Neo4j의 한계
4. 그 외 PostgreSQL의 특징
heading
, code
, image
)을 유연하게 저장하는데 이 모델이 매우 유리하다.language
, 이미지 블록의 url
)을 유연하게 저장하고 빠르게 쿼리할 수 있다. 이는 복잡한 스키마를 가진 NoSQL의 장점과 관계형 데이터베이스의 안정성을 결합한 효과를 낸다.WITH RECURSIVE
): 노션과 같은 페이지에서 '페이지 내의 페이지' 기능으로 복잡한 계층 구조를 가진다. PostgreSQL의 WITH RECURSIVE
쿼리는 이러한 부모-자식 관계를 효율적으로 탐색하여 특정 페이지의 모든 하위 페이지를 빠르고 쉽게 조회할 수 있도록 해준다.WITH RECURSIVE
같은 강력한 재귀 쿼리 기능을 네이티브로 지원하지 않는다. 따라서 페이지 내 페이지와 같은 복잡한 계층 구조를 조회할 때, 어플리케이션 레벨에서 여러 번의 쿼리를 반복하거나, 복잡하고 비효율적인 쿼리(self-join)를 작성해야 한다. 이는 데이터가 많아질수록 성능 저하로 이어진다.JSON
타입을 지원하지만, PostgreSQL의 JSONB 만큼 효율적이지 않다. MySQL의 JSON
타입은 데이터를 단순히 텍스트 형태로 저장하기 때문에, JSON
데이터 내부의 특정 키-값 쌍을 검색할 때 전체 내용을 스캔해야 하는 경우가 많다. 반면, PostgreSQL의 JSONB
는 데이터를 바이너리 형태로 저장하고 전용 인덱스(GIN
인덱스)를 지원하여 훨씬 바른 검색 성능을 제공한다.배열
, hstore
와 같은 고급 데이터 타입을 지원하지 않는다. 이는 노션과 같은 다양한 블록 속성(예: 할 일 목록 내 여러 항목)을 표현하기 위해 별도의 테이블을 만들거나 복잡한 문자열 파싱 로직을 추가해야 함을 의미한다.block
순서(position
), 각 블록의 복잡한 JSONB
콘텐츠를 그래프 모델로 표현하고 관리하는 것은 비효율적입니다. block 순서를 관계 속성으로 관리하거나, 블록을 별도의 노드로 만들어야 하는데, 이는 데이터 모델을 지나치게 복잡하게 만든다.복합적 쿼리 수행의 어려움: 노션에서 페이지 내의 모든 블록을 순서대로 가져오는 쿼리나, 페이지의 소유자/권한을 확인하는 쿼리는 단순한 관계 탐색을 넘어선다. Neo4j는 이러한 복합적인 쿼리를 관계형 데이터베이스만큼 직관적으로 처리하기 어렵다. 반면, PostgreSQL은 JOIN
과 JSONB
쿼리 함수를 통해 이 모든 정보를 하나의 쿼리에서 효율적으로 조합할 수 있다.