LLM WikiAccess-protected knowledge portal

WIKI

PostgreSQL 19 Beta 3 프리뷰: REPACK CONCURRENTLY·SQL/PGQ 그래프 쿼리·논리 복제 개선이 바꾸는 것들

요약 2026년 8월 13일, PostgreSQL 글로벌 개발 그룹은 PostgreSQL 19 Beta 3를 공개했다. 동시에 PostgreSQL 14의 EOL End of Life 예고가 함께 발표됐다. Beta 3는 기능 동결 feature freeze 이후의 안정화 단계이므로 출시 전 최종 기능 목록에 해당한다. 세 가지 변화가 특히 주목할 만하다. 첫째, REPACK CONCURRENTLY 명령이 코어에 추가돼 테이블

경로human/study/content/database-frontier/110-postgresql-19-beta3-repack-concurrently-sql-pgq-logical-replication.md
카테고리Study
태그#concurrently #kubernetes #logical #mysql #pgq #replication #sql #study

요약

2026년 8월 13일, PostgreSQL 글로벌 개발 그룹은 PostgreSQL 19 Beta 3를 공개했다. 동시에 PostgreSQL 14의 EOL(End of Life) 예고가 함께 발표됐다. Beta 3는 기능 동결(feature freeze) 이후의 안정화 단계이므로 출시 전 최종 기능 목록에 해당한다.

세 가지 변화가 특히 주목할 만하다. 첫째, REPACK CONCURRENTLY 명령이 코어에 추가돼 테이블 잠금 없이 공간 회수와 재정렬을 동시에 처리한다. 둘째, SQL/PGQ(Property Graph Queries)가 도입돼 기존 관계형 테이블 위에서 그래프 쿼리를 실행할 수 있게 됐다. 셋째, 논리 복제가 시퀀스 값 복제와 wal_level 무중단 변경을 지원하며 실용성이 높아졌다. PostgreSQL 19의 정식 출시는 2026년 9월로 예정돼 있다.


REPACK CONCURRENTLY: pg_repack을 코어로

기존 방식의 문제

PostgreSQL의 VACUUM FULL은 테이블을 처음부터 다시 쓰며 가비지를 제거한다. 이 과정에서 테이블에 ACCESS EXCLUSIVE 잠금이 걸려 해당 테이블을 읽거나 쓰는 모든 쿼리가 블로킹된다. 대용량 테이블에서는 수 시간이 걸릴 수 있어 운영 중인 시스템에서 실행하기 어렵다.

CLUSTER 명령도 마찬가지다. 인덱스 기준으로 테이블을 물리적으로 재정렬해 쿼리 성능을 개선하지만, 역시 테이블 전체 잠금이 필요하다.

이 한계를 우회하려고 pg_repack 확장이 널리 사용됐다. pg_repack은 원본 테이블에 트리거를 붙이고 병렬 테이블을 만들어 점진적으로 데이터를 복사하는 방식으로 논블로킹 재팩을 구현한다. 하지만 서드파티 확장이라 버전 호환성 관리, 설치 권한, 업그레이드 시점마다 추가 작업이 필요했다.

PostgreSQL 19의 REPACK

PostgreSQL 19는 이 기능을 코어 명령으로 통합했다.

-- 잠금 없이 테이블 재팩 (공간 회수 + 재정렬)
REPACK TABLE orders CONCURRENTLY;

-- 특정 인덱스 기준으로 재정렬하면서 논블로킹 재팩
REPACK TABLE orders USING INDEX orders_created_at_idx CONCURRENTLY;

CONCURRENTLY 옵션을 사용하면 재팩이 진행되는 동안 테이블에 대한 읽기와 쓰기가 그대로 가능하다. 짧은 잠금 취득은 최종 스왑 단계에서만 발생하며, 이 구간도 가능한 한 짧게 유지된다.

CONCURRENTLY 없이 실행하면 기존 VACUUM FULL과 유사하게 독점 잠금을 사용하지만, 단일 명령으로 공간 회수와 재정렬을 동시에 처리하는 편의성이 있다.


SQL/PGQ: 관계형 데이터베이스에서 그래프 쿼리

그래프 쿼리가 필요한 상황

관계형 데이터베이스에 저장된 데이터 중 상당수는 본질적으로 그래프 구조다. 소셜 네트워크의 팔로우 관계, 조직도, 공급망 의존성, 금융 거래 네트워크 등이 대표적인 예다.

지금까지는 이런 데이터를 쿼리할 때 재귀 CTE(Common Table Expression)를 쓰거나, 별도의 그래프 데이터베이스(Neo4j 등)로 데이터를 복제해야 했다. 재귀 CTE는 복잡한 트래버설 패턴을 표현하기 어렵고, 별도 그래프 데이터베이스는 동기화 비용과 운영 복잡성을 추가한다.

PostgreSQL 19의 SQL/PGQ 구현

SQL/PGQ는 ISO SQL:2023 표준의 일부다. PostgreSQL 19는 이 표준을 구현해 CREATE PROPERTY GRAPHGRAPH_TABLE 함수를 제공한다.

그래프 뷰를 정의하는 방법:

CREATE PROPERTY GRAPH social_graph
  VERTEX TABLES (
    users KEY (user_id)
      PROPERTIES (user_id, name, joined_at)
  )
  EDGE TABLES (
    follows
      SOURCE KEY (follower_id) REFERENCES users (user_id)
      DESTINATION KEY (followee_id) REFERENCES users (user_id)
      PROPERTIES (followed_at)
  );

정의된 그래프 위에서 경로 탐색 쿼리를 실행하는 방법:

SELECT gt.follower_name, gt.followee_name, gt.path_length
FROM GRAPH_TABLE (
  social_graph
  MATCH (a IS users) -[e IS follows]->+ (b IS users)
  WHERE a.user_id = 42
  COLUMNS (
    a.name AS follower_name,
    b.name AS followee_name,
    path_length(e) AS path_length
  )
) AS gt;

->+는 하나 이상의 엣지를 따라가는 경로를 의미한다. 데이터는 기존 관계형 테이블(users, follows)에 그대로 있으며, CREATE PROPERTY GRAPH는 뷰처럼 동작해 별도 데이터 마이그레이션이 필요 없다.


아키텍처 다이어그램

REPACK CONCURRENTLY
VACUUM FULL / CLUSTER
ACCESS EXCLUSIVE 잠금
서비스 중단 위험
↓ PostgreSQL 19
REPACK CONCURRENTLY
읽기/쓰기 허용 상태에서
공간 회수 + 재정렬
SQL/PGQ 그래프 쿼리
기존 관계형 테이블
users, follows, orders…
↓ CREATE PROPERTY GRAPH
그래프 뷰 (데이터 이동 없음)
↓ GRAPH_TABLE 함수
경로 탐색 · 패턴 매칭
별도 그래프 DB 불필요
논리 복제 개선
PostgreSQL 18 이전
시퀀스 복제 불가
wal_level 변경 = 재시작
↓ PostgreSQL 19
시퀀스 값 복제 지원
wal_level=replica 시
재시작 없이 활성화
성능·옵티마이저 개선
LZ4 기본 TOAST 압축
기존 pglz 대비 압축 속도 개선
NOT IN → ANTI JOIN
자동 변환으로 쿼리 플랜 개선
pg_plan_advice
쿼리 플래너 결정 저장·재적용
PostgreSQL 19 주요 기능 개요

논리 복제 개선

시퀀스 값 복제

논리 복제는 PostgreSQL 10부터 지원됐지만 한 가지 오랜 한계가 있었다. 시퀀스(SEQUENCE) 값이 복제되지 않아 페일오버 시 키 충돌이 발생할 수 있었다. 주 서버에서 SERIAL 또는 GENERATED ALWAYS AS IDENTITY 컬럼의 시퀀스가 100까지 진행됐더라도, 논리 복제본은 그 정보를 받지 못했다.

PostgreSQL 19는 시퀀스 값을 논리 복제 스트림에 포함시켜 이 문제를 해결한다. 페일오버 후 복제본이 주 서버로 승격될 때 시퀀스가 이어받는 지점이 정확해진다.

wal_level 무중단 변경

논리 복제를 시작하려면 wal_level = logical이어야 한다. PostgreSQL 18까지는 wal_level을 변경하면 서버 재시작이 필요했다. 특히 기존에 wal_level = replica로 운영하다 논리 복제를 추가할 때 짧은 서비스 중단이 불가피했다.

PostgreSQL 19에서는 wal_level이 이미 replica 이상으로 설정된 경우에 한해 논리 복제를 재시작 없이 활성화할 수 있다. 운영 중인 서버에서 다운타임 없이 논리 복제를 추가하는 경우에 실용적인 개선이다.


옵티마이저·성능 개선

NOT IN → ANTI JOIN 자동 변환

NOT IN 서브쿼리는 PostgreSQL이 효율적인 실행 계획을 세우기 어려운 패턴이었다. 특히 서브쿼리 결과에 NULL이 포함될 가능성을 처리해야 해서 항상 ANTI JOIN보다 느린 실행 계획이 선택됐다.

PostgreSQL 19의 옵티마이저는 서브쿼리 결과에 NULL이 포함될 수 없음을 증명할 수 있는 경우(NOT NULL 제약 등)에 NOT IN을 자동으로 ANTI JOIN으로 변환한다. 기존 쿼리 수정 없이 성능 개선을 기대할 수 있다.

LZ4 기본 TOAST 압축

PostgreSQL은 행의 특정 컬럼 값이 일정 크기를 초과하면 TOAST(The Oversized-Attribute Storage Technique) 메커니즘으로 압축·저장한다. PostgreSQL 18까지 기본 TOAST 압축 알고리즘은 pglz였다.

PostgreSQL 19는 기본값을 LZ4로 변경했다. LZ4는 pglz보다 압축 속도가 빠르고 압축 해제 속도는 훨씬 빠르다. 텍스트·JSON·XML 컬럼이 많은 워크로드에서 TOAST 해제 비용이 줄어 쿼리 성능이 향상된다.

pg_plan_advice / pg_stash_advice

두 개의 새로운 확장이 코어와 함께 제공된다.

pg_plan_advice는 쿼리 플래너의 결정을 실행 시점에 덮어쓸 수 있는 힌트 메커니즘을 제공한다. 기존에는 enable_seqscan = off 같은 세션 수준 파라미터나 확장을 사용해야 했지만, pg_plan_advice는 쿼리 패턴과 힌트를 직접 연결하는 구조적인 방법을 제공한다.

pg_stash_advice는 pg_plan_advice와 연동해 힌트를 영속적으로 저장한다. 서버 재시작 이후에도 설정한 플래너 힌트가 유지된다.


AIO 프레임워크 확장

PostgreSQL 18에서 도입된 비동기 I/O(AIO) 서브시스템은 순차 스캔, 비트맵 힙 스캔, VACUUM 등의 성능을 크게 개선했다. PostgreSQL 19는 이 프레임워크를 I/O 워커 자동 스케일링으로 확장한다.

PostgreSQL 18의 AIO는 병렬 I/O 워커 수가 정적으로 설정됐다. PostgreSQL 19에서는 워크로드에 따라 I/O 워커가 자동으로 늘어나고 줄어든다. I/O 바운드 워크로드에서 특히 효과적이다.


PostgreSQL 14 EOL 예고

PostgreSQL 19 Beta 3 발표와 함께 PostgreSQL 14의 지원 종료가 예고됐다. PostgreSQL 프로젝트는 각 메이저 버전을 5년간 지원하며, PostgreSQL 14는 2021년 10월에 출시됐다.

PostgreSQL 14를 아직 사용 중인 경우 업그레이드 계획을 세울 시점이다. 주요 업그레이드 경로:

pg_upgrade를 이용한 인플레이스 업그레이드나 논리 복제를 이용한 무중단 마이그레이션 모두 지원된다.


버전별 주요 기능 비교

기능PostgreSQL 17PostgreSQL 18PostgreSQL 19
비동기 I/O없음도입 (정적 워커)AIO 워커 자동 스케일링
TOAST 기본 압축pglzpglzLZ4
논리 복제 시퀀스없음없음지원
그래프 쿼리없음없음SQL/PGQ
논블로킹 재팩pg_repack 확장pg_repack 확장REPACK CONCURRENTLY (코어)
NOT IN 최적화수동수동자동 ANTI JOIN 변환

정리

PostgreSQL 19 Beta 3는 DBA와 애플리케이션 개발자 모두에게 실용적인 변화를 가져온다. REPACK CONCURRENTLY는 오랫동안 확장에 의존해온 테이블 관리 작업을 코어로 통합하고, SQL/PGQ는 별도 그래프 데이터베이스 없이 관계형 데이터를 그래프로 탐색할 수 있는 새로운 패러다임을 제공한다. 논리 복제 개선과 ANTI JOIN 자동 변환은 운영 편의성과 쿼리 성능을 높인다. 2026년 9월 GA를 앞두고 PostgreSQL 14 환경의 업그레이드 계획을 검토할 시점이다.


References