PostgreSQL 19 REPACK, 새벽 점검이 줄어든다

PostgreSQL을 운영하면서 테이블이 비대해졌을 때 쓸 수 있는 수단은 두 가지였다. VACUUM FULL은 디스크를 회수하지만 테이블 전체에 배타 잠금을 건다. CLUSTER는 인덱스 순서로 재정렬하지만 역시 잠근다. 둘 다 운영 중에는 쓰기 어려워서, 결국 새벽 점검 시간에 몰아서 했다. 2026년 9~10월에 나올 PostgreSQL 19의 REPACK 명령이 이 상황을 바꾼다. 이 글은 19의 주요 변화와, 운영자 관점에서 무엇을 먼저 볼지를 정리한다.

REPACK 이 무엇을 합치나

REPACK은 기존 두 명령의 기능을 합친 것이다. 디스크 공간을 회수하면서 테이블 내용을 재구성한다. 그리고 CONCURRENTLY 옵션을 주면 읽기와 쓰기를 막지 않고 수행한다.

이 기능이 반가운 이유는, 지금까지 같은 일을 하려면 pg_repack이라는 외부 확장을 깔아야 했기 때문이다. 널리 쓰이긴 했지만 확장이라 설치와 버전 관리가 따로 필요했고, 관리형 데이터베이스 서비스에서는 지원 여부가 갈렸다. 코어에 들어오면 이 문제가 사라진다.

다만 CONCURRENTLY가 공짜는 아니다. 원본을 건드리지 않고 새 저장 공간을 만들어 옮기는 방식이므로, 작업 중에는 테이블 크기만큼의 디스크 여유가 더 필요하다. 디스크가 부족해서 정리하려는 상황이라면 오히려 곤란할 수 있다. 여유가 없을 때는 파티션 단위로 나눠서 처리하는 편이 낫다.

오토배큠이 똑똑해졌다

19에서 눈에 덜 띄지만 실무 영향이 큰 변화가 오토배큠 쪽이다.

두 가지가 바뀐다. 하나는 인덱스 배큠에 병렬 워커를 쓸 수 있게 된 것이다. 인덱스가 여러 개 달린 큰 테이블에서 배큠이 오래 걸리던 이유 중 하나가 인덱스를 순차적으로 처리했기 때문인데, 이게 병렬화된다.

다른 하나는 우선순위 점수 체계다. 지금까지 오토배큠은 임계값을 넘은 테이블을 발견 순서대로 처리했다. 그래서 정말 급한 테이블이 뒤로 밀리는 일이 있었다. 새 점수 체계는 어느 테이블이 가장 배큠이나 분석이 필요한지 계산해서 순서를 정한다.

운영 관점에서 이건 "설정을 안 바꿔도 좋아지는" 종류의 개선이다. 오토배큠 파라미터를 테이블마다 손으로 조정해 온 팀이라면, 19로 올린 뒤 그 조정이 여전히 필요한지 다시 볼 만하다.

논리 복제에서 두 가지가 풀렸다

논리 복제를 써 본 사람이라면 시퀀스 때문에 겪은 문제를 기억할 것이다. 테이블 데이터는 복제되는데 시퀀스 값은 복제되지 않아서, 장애 조치 후 구독자 쪽에서 기본 키 충돌이 났다. 이걸 피하려고 수동으로 시퀀스를 맞추는 스크립트를 돌리는 것이 관행이었다.

19에서 시퀀스 값이 복제된다. 장애 조치 절차가 그만큼 단순해진다.

또 하나는 wal_level이 replica인 상태에서 서버 재시작 없이 논리 복제를 켤 수 있게 된 것이다. 기존에는 wal_level을 logical로 바꾸고 재시작해야 했다. 운영 중인 데이터베이스를 재시작하는 것은 계획과 승인이 필요한 일이라, 이 제약 때문에 논리 복제 도입을 미루는 경우가 많았다.

계획을 사람이 거들 수 있게 된다

pg_plan_advice는 성격이 다른 기능이다. 플래너에게 조언을 주는 틀을 제공한다. 계획 조언 문자열을 생성하고, 다른 모듈이 계획 수립 시점에 조언을 끼워 넣을 수 있는 훅을 연다.

PostgreSQL은 전통적으로 옵티마이저 힌트를 제공하지 않는 쪽을 고수해 왔다. 힌트가 있으면 사람들이 통계를 고치는 대신 힌트로 땜질하고, 데이터가 변해도 그 힌트가 남아 오히려 느려진다는 것이 이유였다. Oracle이나 MySQL에서 넘어온 사람들이 가장 답답해하는 지점이기도 했다.

pg_plan_advice는 그 철학을 완전히 뒤집는 것은 아니지만, 계획이 갑자기 나빠졌을 때 긴급하게 고정할 수단을 코어 쪽에 마련한다는 의미가 있다. 실제로 어떻게 쓰이게 될지는 지켜봐야 한다.

약속됐다가 빠진 기능도 있다

여기서 짚어둘 것이 하나 있다. 19의 기대 기능으로 여러 곳에서 소개됐던 SQL/PGQ 속성 그래프 질의가 정식 릴리스를 앞두고 되돌려졌다. 2026년 9월 7일자로 CREATE PROPERTY GRAPH와 GRAPH_TABLE은 19에 포함되지 않는 것으로 정리됐다.

그래프 질의를 표준 SQL 문법으로 쓸 수 있다는 점에서 주목받던 기능이라 아쉬워하는 사람이 많다. 다만 베타 기간에 발견된 문제로 기능을 빼는 것은 PostgreSQL이 늘 해 온 방식이다. 덜 익은 채로 내보내고 다음 버전에서 호환성을 깨는 것보다 낫다.

이 사례가 주는 교훈은 실무적이다. 베타 단계의 기능 소개를 근거로 도입 계획을 세우면 안 된다. 정식 릴리스 노트가 나온 뒤에 확정하는 것이 맞다. 기술 블로그를 읽을 때도 그 글이 베타 시점에 쓰였는지 확인하는 습관이 필요하다.

언제 올릴 것인가

PostgreSQL 메이저 버전은 매년 가을에 나오고, 각 버전은 5년간 지원된다. 그래서 무리해서 최신을 쫓을 이유는 없다.

내 기준은 이렇다. .1 패치가 나온 뒤에 올린다. 메이저 릴리스 직후에는 드물게 회귀 버그가 발견되고, 대개 첫 패치에서 정리된다. 특히 19처럼 저장 구조나 배큠 동작에 손을 댄 버전이라면 서두를 이유가 없다.

올리는 이유가 분명해야 한다는 것도 중요하다. 위 기능 중 내가 실제로 겪고 있는 문제를 푸는 것이 있는지 본다. 배큠 때문에 새벽마다 점검을 하고 있다면 REPACK은 충분한 이유가 된다. 논리 복제를 쓰는데 시퀀스를 손으로 맞추고 있다면 그것도 이유가 된다. 해당 사항이 없다면 다음 해에 올려도 된다.

메이저 업그레이드 전에 해두는 준비

PostgreSQL 메이저 업그레이드는 마이너와 성격이 다르다. 저장 포맷이 바뀔 수 있어서 pg_upgrade나 논리 복제를 써야 한다. 준비 순서를 정리하면 이렇다.

확장(extension) 목록을 먼저 본다. SELECT * FROM pg_extension;으로 확인하고, 각 확장이 새 메이저 버전을 지원하는지 확인한다. PostGIS나 TimescaleDB처럼 무거운 확장은 업그레이드 순서에 제약이 있다.

pg_upgrade --check를 먼저 돌린다. 실제로 옮기지 않고 문제만 점검한다. 여기서 걸리는 것을 미리 정리해 두면 실제 작업 시간이 줄어든다.

업그레이드 직후에 ANALYZE를 돌린다. pg_upgrade는 통계 정보를 가져가지 않는다. 이걸 빠뜨리면 옵티마이저가 통계 없이 계획을 세워서, 업그레이드 후에 갑자기 느려진다. 원인을 몰라 헤매는 대표적인 사례다.

되돌릴 방법을 정해 둔다. pg_upgrade --link는 빠르지만 되돌릴 수 없다. 복사 방식은 느리지만 원본이 남는다. 다운타임 여유와 위험 감수 정도에 따라 고른다.

새 기능이 반가운 것과 별개로, 업그레이드 자체는 늘 보수적으로 하는 편이 낫다.

참고 자료

• PostgreSQL: Documentation: 19: E.1. Release 19 — 공식 릴리스 노트
• PostgreSQL 19 features I'm excited about — Bytebase — REPACK, 오토배큠, 논리 복제 변경의 실무 관점 정리
• PostgreSQL 19 New Features — Neon — 기능별 설명과 SQL/PGQ 되돌림 경위