LLM WikiAccess-protected knowledge portal
← 스터디 홈
3편 · 약 19분

PostgreSQL 19 Beta: 운영자가 GA 전에 미리 알아야 할 변화

"제일 중요한 릴리스" 앞에서 무엇을 준비할 것인가

PostgreSQL 19 Beta 1이 2026년 6월 4일에 공개됐다. GA는 2026년 9~10월로 예상된다. 릴리스 전에 베타를 미리 살펴보는 이유는 테스트 외에도 하나 더 있다. 운영 환경에서 어떤 변화가 일어날지 미리 파악하고 준비하는 것이다.

이번 릴리스는 pg_repack 사용자, autovacuum을 손으로 튜닝하는 팀, 읽기 복제본에서 read-your-writes를 구현한 팀, 외래 키 성능 문제를 겪은 팀 모두에게 직접 관련이 있다. 개별 기능의 API 변화보다 "내 운영 환경에서 무엇이 달라지는가"에 초점을 맞춰 살펴본다.

이 장은 PostgreSQL 19 Beta 1 릴리스 노트, 공식 문서, 및 개발자 커뮤니티 분석 자료를 기준으로 한다. Beta 단계이므로 GA 전에 세부 동작이 변경될 수 있다. 운영 투입 전에 반드시 최종 릴리스 노트를 확인한다.

변화 전체 지도

PostgreSQL 19 Beta 1 — 운영자 관점 주요 변화 🔧 운영·유지보수 REPACK [CONCURRENTLY] pg_repack/VACUUM FULL 대체. 잠금 최소화 Parallel Autovacuum autovacuum_max_parallel_workers 신설. 인덱스 병렬 처리 pg_plan_advice 플래너 힌트와 실행계획 안정화 지원 🔁 복제·가용성 WAIT FOR LSN 복제본이 특정 LSN까지 따라잡을 때까지 대기 논리 복제 개선 재시작 없이 활성화. Sequence 복제 지원 외래 키 성능 2× FK 검증 잠금 최적화로 INSERT 처리량 향상 🔍 SQL·쿼리 SQL/PGQ (그래프 쿼리) ISO SQL:2023 Part 16. 관계형 테이블 위 그래프 쿼리 Atomic Upsert INSERT ... ON CONFLICT 잠금 경합 개선 ⚙️ 기본값 변경 — 기존 환경에서 동작이 달라질 수 있음 JIT 기본값 OFF 단순 쿼리 overhead 제거 TOAST 기본 압축 → lz4 pglz 대비 압축·해제 속도 개선 RADIUS 인증 제거 pg_hba.conf 영향 확인 필요 autovacuum 우선순위 점수 시스템 테이블별 vacuum 필요도 자동 계산 Beta 1 기준 (2026-06-04). GA(9~10월 예정) 전 릴리스 노트 재확인 권장.
PostgreSQL 19 Beta 주요 변화 개요

REPACK: pg_repack을 내장으로 대체하다

기존 상황

테이블 bloat를 제거하려면 두 가지 선택지가 있었다.

  • VACUUM FULL: ACCESS EXCLUSIVE 잠금. 실행 중에 테이블 전체가 잠긴다. 중·대형 테이블에서는 사용이 사실상 불가능하다.
  • pg_repack: 외부 확장. 배포 파이프라인에서 버전 관리가 따로 필요하고, PostgreSQL 메이저 버전 업그레이드마다 확장도 같이 업그레이드해야 한다.

PostgreSQL 19의 해결

REPACK 명령이 내장됐다. 핵심은 CONCURRENTLY 옵션이다.

-- 기본: VACUUM FULL과 동일한 ACCESS EXCLUSIVE (블로킹)
REPACK TABLE orders;

-- CONCURRENTLY: 대부분의 작업이 비블로킹
REPACK TABLE orders CONCURRENTLY;

CONCURRENTLY 모드의 작동 순서는 다음과 같다.

  1. 새 테이블 파일을 생성한다.
  2. 원본 테이블을 SHARE UPDATE EXCLUSIVE로 잠그고(읽기·쓰기 가능) 데이터를 복사한다.
  3. 복사 중 발생한 변경을 별도 추적한다.
  4. 변경 차이를 적용한다.
  5. 마지막 파일 교체 시점에만 ACCESS EXCLUSIVE를 짧게 획득한다.
  6. 이전 파일을 삭제한다.

테이블은 대부분의 과정에서 읽기·쓰기가 가능하다. 잠금은 최종 파일 교체 순간에만 발생한다.

운영 고려사항

CONCURRENTLY는 제약이 있다. 복사 과정에서 추가 I/O와 스토리지가 필요하다. 트랜잭션 안에서 실행할 수 없다. 완료 시간이 예측하기 어렵다. pg_repack을 사용하던 팀은 동작 방식을 비교한 뒤 전환 여부를 결정해야 한다.

pg_repack은 여전히 동작한다. 19에서 내장 REPACK이 생겼어도 즉시 제거되진 않으나, 장기적으로는 내장 버전으로 마이그레이션하는 것이 유지보수 부담을 줄인다.

Parallel Autovacuum: 인덱스 청소가 병렬로

기존 문제

autovacuum worker는 테이블당 하나다. 테이블에 인덱스가 많을수록 vacuum이 오래 걸린다. 인덱스 5개를 순차 처리하는 동안 dead tuple이 쌓이고, XID wraparound 위험이 높아질 수 있다.

PostgreSQL 19의 변화

autovacuum_max_parallel_workers 파라미터가 추가됐다. 이 값을 설정하면 worker 하나가 여러 인덱스를 병렬로 처리할 수 있다.

-- postgresql.conf
autovacuum_max_parallel_workers = 4   -- worker당 최대 병렬 워커 수

추가로 테이블별 vacuum 우선순위 점수 시스템이 도입됐다. dead tuple 비율, 최근 vacuum 시점, 트랜잭션 나이 등을 종합해 가장 vacuum이 급한 테이블을 우선 처리한다.

운영 고려사항

병렬 vacuum은 I/O를 더 많이 사용한다. autovacuum_max_parallel_workers를 높이면 디스크 I/O와 CPU가 올라간다. 기존 vacuum 모니터링(pg_stat_user_tables, pg_stat_activity)에서 병렬 worker가 어떻게 보이는지 확인하고 대시보드를 업데이트한다.

WAIT FOR LSN: 복제본에서 read-your-writes

기존 문제

primary에 쓴 직후 복제본에서 읽으면 아직 복제가 도착하지 않아 직전 쓰기가 보이지 않는다. read-your-writes를 구현하려면 보통 이런 방식을 썼다.

  • 쓰기 후 pg_current_wal_lsn()으로 LSN을 받아 클라이언트에 전달한다.
  • 복제본 세션에서 pg_last_wal_replay_lsn()을 폴링해 target LSN 이상이 되길 기다린다.
  • 폴링 로직은 애플리케이션이 직접 구현해야 했다.

PostgreSQL 19의 해결

-- 복제본 세션에서: target_lsn까지 따라잡을 때까지 기다림
SELECT WAIT FOR LSN '0/3F000000' TIMEOUT 5000;
-- TIMEOUT은 밀리초. 시간 내에 못 따라잡으면 오류 반환

복제본 세션이 직접 LSN을 대기할 수 있다. 애플리케이션의 폴링 루프를 데이터베이스 레이어로 옮길 수 있다.

이 기능은 primary에서 LSN을 받아 복제본 라우팅 단에서 활용하는 패턴과 결합하면 읽기 복제본 라우팅을 보다 정교하게 만들 수 있다.

SQL/PGQ: 관계형 테이블 위에서 그래프를 쿼리하다

SQL/PGQ(SQL Property Graph Queries)는 ISO SQL:2023 Part 16 표준이다. 별도 그래프 데이터베이스를 두지 않고, 기존 관계형 테이블 위에서 그래프 패턴 매칭 쿼리를 실행한다.

-- 1. 그래프 뷰 정의
CREATE PROPERTY GRAPH company_graph
  VERTEX TABLES (employees KEY (emp_id))
  EDGE TABLES (
    reports_to KEY (emp_id) SOURCE KEY (emp_id) REFERENCES employees
                            DESTINATION KEY (manager_id) REFERENCES employees
  );

-- 2. 그래프 쿼리: 3단계 이하 보고 체계 찾기
SELECT *
FROM GRAPH_TABLE (company_graph
  MATCH (e:employees) -[:reports_to]->* {1,3} (m:employees)
  WHERE m.name = 'Alice'
  COLUMNS (e.name AS employee, m.name AS manager)
) AS g;

이 쿼리는 employees와 reports_to 테이블에서 Alice까지 1~3단계로 연결된 모든 직원을 찾는다. 데이터 마이그레이션 없이 기존 테이블에서 바로 실행된다.

어떤 상황에서 유용한가

  • 의존성 분석: 서비스 간 호출 관계, 테이블 간 참조 관계를 재귀 CTE 없이 표현
  • 추천 시스템: 사용자-아이템 이분 그래프에서 k-hop 이내 연결 찾기
  • 보안 감사: 접근 권한의 상속 체계를 그래프로 탐색

그래프 데이터베이스 도입 없이 기존 PostgreSQL 인프라에서 그래프 쿼리가 필요한 팀에게 실용적인 선택지가 생긴다.

Open question: 대규모 그래프(수억 개의 edge)에서의 성능은 GA 이후 실측 데이터가 더 쌓여야 평가 가능하다.

외래 키 성능: INSERT 속도 2배

외래 키 제약이 있는 테이블에 INSERT할 때 PostgreSQL은 참조 테이블의 해당 행에 잠금을 걸어 무결성을 보장한다. 이 잠금 방식의 비효율 때문에 FK가 많은 테이블에서 고빈도 INSERT 처리량이 제한됐다.

PostgreSQL 19에서 FK 검증 시 필요한 잠금 범위를 줄였다. 측정 결과 FK 부하가 있는 환경에서 INSERT 처리량이 약 2배 향상됐다.

OLTP처럼 참조 무결성을 FK로 강제하면서 빠른 쓰기가 필요한 환경에서 실질적인 이득이다. FK를 성능 이유로 비활성화한 팀이라면 재검토할 가치가 있다.

논리 복제 개선

두 가지 운영상 중요한 변화가 있다.

재시작 없이 논리 복제 활성화: 기존에는 wal_level = logical로 바꾸려면 서버 재시작이 필요했다. 이 제약이 해제된다. 다운타임 없이 논리 복제를 켤 수 있다.

Sequence 복제 지원: 논리 복제 대상에 시퀀스가 포함된다. primary와 복제본 간 시퀀스 값의 불일치로 인한 문제를 줄일 수 있다. zero-downtime 마이그레이션이나 active-active 구성을 고려하는 팀에게 관련이 있다.

기본값 변경: 꼭 확인해야 할 것들

JIT 기본값 OFF

PostgreSQL 10에서 도입된 JIT(Just-In-Time) 컴파일이 기본값에서 꺼진다. JIT는 복잡한 OLAP 쿼리에서 실행 속도를 올릴 수 있지만, 단순 OLTP 쿼리에서는 컴파일 overhead만 추가됐다.

기존에 JIT를 의도적으로 활용하는 쿼리가 있다면 세션 레벨이나 쿼리 레벨에서 명시적으로 켜야 한다.

SET jit = on;  -- 세션 레벨

-- 또는 쿼리 레벨 hint (pg_hint_plan과 함께 사용)

lz4를 TOAST 기본 압축으로

default_toast_compression의 기본값이 pglz에서 lz4로 바뀐다. lz4는 압축·해제 속도에서 pglz보다 빠르고, 압축률은 비슷하거나 약간 낮다.

이미 저장된 데이터는 영향 없다. 새로 INSERT·UPDATE되는 TOAST 대상 데이터부터 lz4가 적용된다. lz4 지원이 없는 매우 오래된 클라이언트 라이브러리나 pg_dump 버전을 사용하는 경우 호환성을 확인한다.

RADIUS 인증 방식 제거

pg_hba.conf에서 radius 방식을 사용하는 경우 대안을 마련해야 한다. LDAP이나 GSSAPI 등 지원되는 인증 방식으로 마이그레이션이 필요하다.

pg_plan_advice: 플래너 힌트를 내장으로

PostgreSQL은 전통적으로 쿼리 힌트를 공식 지원하지 않았다. pg_hint_plan 같은 외부 확장이 이 역할을 했다.

pg_plan_advice 확장이 내장으로 추가된다. 특정 쿼리 ID에 대해 플래너 결정을 고정하거나 유도할 수 있다. pg_stash_advice는 현재 실행계획을 쿼리 ID와 함께 저장해 이후 자동으로 적용한다.

플래너가 통계 오류로 나쁜 실행계획을 선택하는 특정 쿼리에 대해 임시 대응 수단으로 쓸 수 있다. 외부 확장 없이 내장 메커니즘으로 같은 효과를 낼 수 있게 된다.

GA 전 운영팀 준비 체크리스트

기본값 변경 영향 확인
JIT가 OFF가 됨을 인식하고, JIT 성능 이득을 기대하는 쿼리가 있다면 세션 레벨로 ON을 명시한다.
TOAST lz4 변경은 신규 데이터에만 적용됨을 확인한다. 구버전 클라이언트 라이브러리와 호환성을 점검한다.
pg_hba.conf에 radius 방식이 있다면 지금 대안을 검토한다. GA 전에 마이그레이션 계획을 세운다.
신기능 테스트 우선순위
REPACK CONCURRENTLY를 스테이징에서 실제 bloat 테이블에 실행해본다. 소요 시간과 I/O를 기존 pg_repack과 비교한다.
autovacuum_max_parallel_workers를 인덱스가 많은 테이블이 있는 환경에서 테스트한다. I/O 증가와 vacuum 단축 시간을 함께 측정한다.
WAIT FOR LSN을 읽기 복제본에서 read-your-writes를 구현하는 코드에 적용해보고 기존 폴링 로직을 대체할 수 있는지 확인한다.
복제 환경 검토
논리 복제를 사용한다면 재시작 없이 wal_level 변경이 가능해지는 것의 의미와 영향을 확인한다.
시퀀스 복제가 필요한 시나리오가 있다면 Beta에서 동작을 검증한다. 마이그레이션이나 active-active 구성에서 특히 중요하다.
업그레이드 계획
pg_upgrade를 스테이징에서 먼저 실행해본다. 확장 호환성(pg_repack, pg_hint_plan 등)을 점검한다.
GA 릴리스 노트(9~10월 예정)를 Beta 1 대비 다시 읽고 행동 변경이 추가됐는지 확인한다.
Beta는 프로덕션 투입 금지. 스테이징과 개발 환경에서 기능 검증에 활용한다.
PostgreSQL 19 GA 대비 운영팀 체크리스트

정리

PostgreSQL 19 Beta 1은 오랜 운영 불편을 내장 기능으로 흡수하는 릴리스다. pg_repack은 REPACK CONCURRENTLY로, autovacuum 병목은 autovacuum_max_parallel_workers로, read-your-writes 폴링은 WAIT FOR LSN으로, 외래 키 성능 제약은 잠금 최적화로 대응한다.

SQL/PGQ는 범위가 다르다. 그래프 데이터베이스를 따로 두지 않고 기존 관계형 테이블에서 ISO 표준 그래프 쿼리를 실행할 수 있다. 실용 범위는 GA 이후 실측 경험이 더 쌓여야 명확해질 것이다.

운영팀에게 가장 시급한 것은 기본값 변경 확인이다. JIT OFF와 lz4 TOAST는 대부분의 환경에서 이득이지만, RADIUS 인증을 사용하는 경우는 GA 전에 대안을 마련해야 한다.

References