PostgreSQL 19 Beta 1의 병렬 오토배큠과 SQL/PGQ 운영 변화

PostgreSQL 19 Beta 1의 병렬 오토배큠, AIO 워커 자동 스케일링, SQL/PGQ, REPACK과 도입 검증 항목을 정리한다.

2026-08-14 · 최초 발행 2026-08-02

PostgreSQL 글로벌 개발 그룹(PGDG)은 2026년 6월 4일 PostgreSQL 19의 첫 베타인 Beta 1을 공개했다. 이번 버전은 오토배큠의 병렬 워커, PostgreSQL 18에서 도입된 비동기 I/O(AIO)의 워커 자동 스케일링, SQL:2023 기반 SQL/PGQ를 함께 담았다. 정식 GA는 일반적인 연간 릴리스 주기에 따라 2026년 9~10월경으로 예정되어 있다.

기존 관계형 데이터를 유지한 채 그래프·고동시성·대용량 운영 기능을 코어에 통합한다는 점이 핵심이다. DBA와 SRE에게는 18의 AIO 도입 이후 배큠, 재구성, I/O 병목 관리 방식에 가장 큰 영향을 주는 변화다.

배큠 우선순위와 인덱스 정리를 병렬화한다

기존 오토배큠은 테이블별 단일 워커가 힙 스캔과 인덱스 정리를 순차로 수행했다. 인덱스가 많은 대용량 테이블에서는 배큠 시간이 길어지는 구조였다. PostgreSQL 19는 인덱스 배큠 단계를 병렬 워커에 나눈다.

autovacuum_max_parallel_workers 설정으로 병렬 인덱스 배큠을 제어할 수 있다. 데드 튜플 생성량과 블로트 비율에 따른 스코어링으로 우선 처리할 테이블을 고르고, 일반 병렬 쿼리 워커 풀과 분리된 오토배큠 전용 병렬 워커를 관리한다.

고점수 테이블저점수 테이블오토배큠 런처테이블 스코어링(데드 튜플/블로트)병렬 워커 할당대기열 후순위 스캔 (단일)인덱스 배큠 (병렬 분산)인덱스1 워커인덱스2 워커인덱스N 워커블로트 회수 완료

스코어링이 먼저 처리 대상을 정하고, 이어서 인덱스 배큠을 여러 워커에 분산한다. 다중 인덱스를 가진 테이블의 배큠 시간을 줄이기 위한 구조다.

부하에 맞춰 AIO 워커를 조정한다

PostgreSQL 18은 io_uring·worker 기반 비동기 I/O 서브시스템을 도입했지만, 워커 수는 운영자가 수동으로 고정해야 했다. PostgreSQL 19에서는 io_method=worker일 때 워커 수가 io_min_workersio_max_workers 범위 안에서 부하에 따라 동적으로 조정된다.

EXPLAIN (ANALYZE, IO)는 플랜별 비동기 읽기 대기 비중을 보고한다. 시퀀셜 스캔과 비트맵 힙 스캔처럼 대량 읽기가 발생하는 워크로드에서 스토리지 지연 은닉을 확인하는 데 쓸 수 있다.

PostgreSQL 19부하 증가부하 감소PostgreSQL 18수동 고정 워커쿼리 실행기AIO 서브시스템io_method=worker부하 측정워커 증설(<= io_max_workers)워커 축소(>= io_min_workers)스토리지 비동기 읽기버퍼 적재

이전 버전의 수동 워커 관리와 달리, 부하 변화에 맞춰 워커를 조정해 과소·과대 프로비저닝을 피하는 구조다.

관계형 테이블에서 SQL/PGQ 그래프를 조회한다

SQL/PGQ(SQL Property Graph Queries)는 SQL:2023의 일부다. 기존 관계형 테이블 위에서 그래프 패턴 매칭을 처리하므로 별도 그래프 데이터베이스를 반드시 두지 않아도 된다.

테이블이 노드(vertex)인지 엣지(edge)인지 선언하는 뷰 기반 정의를 사용하며, 이 과정에서 데이터를 옮기지 않는다. MATCH 절로 노드와 엣지의 패턴을 표현하고, 기존 인덱스와 트랜잭션을 그대로 활용한다. 초기 범위는 고정 깊이 패턴 매칭이며, 가변 길이 경로와 최단 경로 알고리즘은 후속 버전 예정이다.

프로퍼티 그래프 (뷰)관계형 테이블 (기존)FOLLOWS노드 매핑엣지 매핑users 테이블follows 테이블노드: User엣지: FOLLOWS

usersfollows 같은 테이블을 노드와 엣지로 매핑하는 방식이다. 지식 그래프, 추천 관계, 이상거래 탐지, 공급망 추적, 조직 계층에는 적합하지만, 수십억 노드를 심층 재귀 순회하는 작업은 전용 그래프 DB가 여전히 유리하다.

충돌 행을 반환하는 업서트 분기

PostgreSQL 19는 INSERT ... ON CONFLICT DO SELECT ... RETURNING을 추가했다. 업서트 시 충돌한 기존 행도 반환할 수 있게 된 것이다.

기존의 DO NOTHING은 충돌 행을 반환하지 않으므로 기존 행의 id가 필요하면 추가 SELECT가 필요했다. DO UPDATE만 영향 행을 반환할 수 있었다. 새 DO SELECT는 충돌 행을 반환해 MERGE 수준의 데이터 반환 동등성을 제공한다.

ON CONFLICT는 MERGE와 달리 경쟁 상태 없이 INSERT 또는 UPDATE를 보장한다. 동시 트랜잭션이 충돌 행을 삭제해도 실패하지 않는다. 외래키 부하 인서트는 최대 2배 향상됐고, 무중단 논리 복제와 WAIT FOR LSN 읽기-쓰기 일관성도 포함된다.

NoYesDO UPDATEDO SELECT (신규)DO NOTHINGINSERT ... ON CONFLICT충돌 발생?신규 INSERT 수행충돌 처리 갱신 + RETURNING충돌 조회 + RETURNING무시 (반환 없음)RETURNING 결과

베타 검증은 업그레이드와 워크로드를 분리해 진행한다

Beta 1은 운영 환경에 투입하지 않고 별도 검증 환경에서 pg_upgrade 시뮬레이션을 수행한다. 확장 호환성도 확인해야 하며, 특히 pg_repack을 사용 중이면 네이티브 REPACK으로의 전환을 평가할 대상이다. Amazon RDS Database Preview 환경 등에서 클라우드 호환성을 미리 시험할 수 있다.

대용량 테이블에서는 가장 크고 인덱스가 많은 테이블을 대상으로 18과 19의 배큠 소요 시간을 비교한다. autovacuum_max_parallel_workers를 0 초과로 설정한 뒤 측정하고, 오토배큠 스코어링이 핫 테이블을 먼저 처리하는지도 부하 테스트로 확인한다.

AIO는 io_method=worker 설정 후 io_min_workersio_max_workers 경계를 조정한다. EXPLAIN (ANALYZE, IO)로 비동기 읽기 대기 비중을 측정하고, NVMe·고IOPS 스토리지에서 시퀀셜 스캔 처리량 개선을 확인한다.

그래프 쿼리는 추천, 이상거래, 조직 계층처럼 고정 깊이 패턴을 갖는 워크로드부터 PoC에 적용한다. 가변 길이 경로가 필요하면 후속 버전 또는 전용 그래프 DB 병행을 검토한다.

YesNo검증 환경 구축pg_upgrade 호환성 테스트오토배큠 18 vs 19 벤치마크AIO 워커 경계 튜닝SQL/PGQ PoCGA 출시?스테이징 운영 점진 적용추가 베타/RC 재검증

GA 전에는 반복 검증을 수행하고, 출시 이후에는 스테이징을 거쳐 점진 적용한다.

PostgreSQL 18·19와 MySQL 9의 운영 기능 비교

항목 PostgreSQL 18 PostgreSQL 19 (Beta) MySQL 9
오토배큠/퍼지 단일 워커 순차 처리 병렬 워커 + 스코어링 우선순위 InnoDB 퍼지 스레드(별도 GC)
비동기 I/O AIO 도입(수동 워커) io 워커 자동 스케일링 제한적 비동기 I/O
그래프 쿼리 미지원(재귀 CTE) SQL/PGQ 네이티브(고정 깊이) 미지원
온라인 테이블 재구성 pg_repack 확장 네이티브 REPACK CONCURRENTLY ALGORITHM=INPLACE 부분 지원
업서트 동시성 ON CONFLICT(DO NOTHING/UPDATE) + DO SELECT ... RETURNING INSERT ... ON DUPLICATE KEY
관측성 기본 EXPLAIN EXPLAIN (ANALYZE, IO) AIO 통계 Performance Schema

PostgreSQL 18이 AIO 도입과 기능 동결에 무게를 뒀다면, 19는 병렬 배큠, 워커 스케일링, 온라인 REPACK 같은 운영 자동화에 집중한다. MySQL은 InnoDB 퍼지 스레드로 GC를 분리하지만 네이티브 그래프 쿼리와 표준 SQL/PGQ는 없다. 이 기준에서는 PostgreSQL이 표준 준수와 확장성 측면에서 우위다.

2026년에는 단일 PostgreSQL 스택에서 관계형·그래프·벡터(pgvector)·HTAP을 통합하는 “Postgres for Everything” 흐름이 가속되고 있다.

DB 엔진 설계 관점에서 읽는 변화

병렬 오토배큠은 MVCC의 데드 튜플 누적 문제를 병렬 GC로 완화해 블로트 관리 비용을 분산한다. AIO 워커 자동 스케일링은 OS 수준 비동기 입출력인 io_uring과 DBMS 버퍼 관리를 결합해 지연 은닉을 최적화하는 방식이다.

SQL/PGQ는 관계형 모델 위에 프로퍼티 그래프 모델을 논리적 뷰로 투영한다. 하나의 스토리지에서 다중 데이터 모델을 지원하는 Multi-Model DB의 사례다. 원자적 업서트로서의 ON CONFLICT는 직렬화 가능성과 경쟁 상태 회피를 보장하는 격리 수준 설계와 연결된다.

운영 전 확인할 제약과 의존성

Beta 1은 운영 환경에 투입하지 않으며, GA가 예정된 2026년 9~10월 이후에도 점진 적용이 필요하다. pg_repack 등 기존 확장을 네이티브 기능으로 대체할 때는 운영 스크립트와 모니터링을 다시 구성해야 한다.

병렬 배큠과 AIO 워커 증가는 CPU·I/O 자원 경합을 만들 수 있으므로 워커 상한을 신중하게 조정한다. SQL/PGQ는 고정 깊이 패턴만 지원하므로 가변 길이와 최단 경로가 필요한 워크로드는 전용 그래프 DB 병행을 검토한다. EXPLAIN (ANALYZE, IO) 같은 진단 도구도 모니터링 파이프라인에 통합할 대상이다.

Sources

PostgreSQL오토배큠비동기 I/OSQL/PGQ데이터베이스 운영