PostgreSQL 19 9월 GA 예정 — 파티셔닝·논리 복제·벡터, 14 EOL 앞둔 업그레이드 전략

매년 9월이면 PostgreSQL 커뮤니티는 새 메이저 버전을 낸다. 벌써 몇 년째 어긋난 적이 없는 리듬이다. 올해 차례는 19번인데, 이 글을 쓰는 2026년 9월 중순 기준으로 아직 GA가 아니라 베타 3다. 그래서 먼저 못을 박아둔다 — 여기서 "19의 새 기능"이라고 말하는 것들은 베타 기준의 예상이고, 릴리스 노트가 확정되기 전까지는 언제든 빠지거나 형태가 바뀔 수 있다. 나는 매번 베타 기능 보고 설레발쳤다가 GA에서 빠져 머쓱했던 적이 몇 번 있어서, 요즘은 "베타는 베타로만" 본다.

그래도 이번 사이클은 남 일이 아니다. 우리 팀은 아직 14를 굴리는 인스턴스가 두 개 남아 있는데, 그게 두 달 뒤 EOL이다. 그러니 이 글은 "새 버전 구경"이 아니라 업그레이드 계획서에 가깝다. 무엇이 오는지, 무엇이 끝나는지, 지금 뭘 해야 하는지 순서대로 정리한다.

날짜·버전은 postgresql.org 공식 발표(2026-08-13 마이너 및 19 베타 3 릴리스) 기준. GA 시점은 커뮤니티 관례상 9월이며, 최종 확정일은 릴리스되어야 확정된다.

PostgreSQL 19는 지금 어디까지 왔나

결론부터: 베타 3이고, GA는 9월 중으로 예정돼 있다. PostgreSQL의 베타 단계는 대개 5월 무렵 베타 1로 시작해 여름 동안 베타 2·3, 필요하면 RC(릴리스 후보)를 거쳐 9월경 정식판으로 굳는다. 베타 3까지 왔다는 건 기능 동결(feature freeze)이 이미 지나 새 기능이 추가되지는 않고, 남은 버그를 잡는 국면이라는 뜻이다. 그래서 지금 베타에 들어 있는 기능 목록은 GA와 거의 같겠지만, "거의"이지 "전부"는 아니다.

실무적으로 지금 할 수 있는 건 두 가지다. 하나는 테스트 환경에서 19 베타를 돌려보는 것 — 특히 확장(extension) 호환성과 쿼리 플랜 변화를 확인하기 좋은 시기다. 다른 하나는 기다리는 것. 프로덕션이라면 나는 후자다. 메이저 첫 릴리스(19.0)는 아무리 테스트를 거쳤어도 초기 마이너(19.1, 19.2)에서 자잘한 걸 잡는 경우가 많아서, 개인적으로는 .1이나 .2가 나온 뒤 올리는 편이다. 급하지 않다면 이 원칙이 대체로 손해가 없었다.

먼저 급한 것 — 8월 13일 마이너 릴리스

19 얘기에 가려졌지만, 지금 당장 반영해야 하는 건 8월 13일 마이너 릴리스다. 현재 지원되는 전 계열(18.6·17.11·16.15·15.19·14.24)에 걸쳐 보안 취약점 28건과 버그 110개 이상을 고쳤다. 마이너 업데이트는 메이저와 달리 데이터 파일 포맷이 바뀌지 않기 때문에, 대개 패키지 교체 후 재시작만으로 끝난다. 다운타임도 짧고 롤백도 쉬워서, 미룰 이유가 거의 없다.

내가 마이너를 미루지 말라고 강하게 말하는 이유가 있다. 보안 수정은 릴리스 노트에 상세가 공개되는 순간부터 공격자에게도 힌트가 된다. "곧 하지 뭐" 하고 분기 하나 넘기면, 그 사이는 알려진 취약점을 그대로 열어두는 창구가 된다. 실무에서 이걸로 데인 적이 있어서, 지금은 마이너 릴리스 알림을 아예 채널에 걸어두고 2주 안에 처리하는 걸 규칙으로 삼는다.

# 현재 서버의 정확한 마이너 버전 확인
psql -c "SHOW server_version;"
# 예: 16.14 로 나오면 16.15 로 올릴 대상

# 데비안/우분투 계열 마이너 업데이트 (예시)
sudo apt update
sudo apt install --only-upgrade postgresql-16
sudo systemctl restart postgresql

# RHEL/Rocky 계열 (PGDG 저장소)
sudo dnf update postgresql16-server
sudo systemctl restart postgresql-16

주의할 건, 이번처럼 보안 수정이 많은 릴리스는 릴리스 노트를 실제로 읽어보는 것이다. 대부분은 재시작으로 끝나지만, 가끔 특정 수정은 인덱스 재생성(REINDEX)이나 함수 재정의 같은 후속 조치를 요구한다. "패치했으니 끝"이 아니라 노트에 적힌 후속 작업(post-upgrade steps)이 있는지 확인하는 습관이 필요하다.

PostgreSQL 14 EOL — 11월 12일, 남은 시간은 두 달

가장 시한이 명확한 항목이다. PostgreSQL 14는 2026년 11월 12일에 EOL(End of Life)이다. 그날 이후로는 보안 패치도, 버그 수정도, 새 마이너 릴리스도 나오지 않는다. 14를 계속 굴린다고 갑자기 서버가 멈추는 건 아니지만, 새로 발견되는 취약점에 대해 공식적으로 무방비 상태가 된다는 뜻이다. 컴플라이언스가 걸린 조직이라면 감사에서 바로 지적당한다.

PostgreSQL은 메이저 버전을 출시 후 5년 지원한다. 14는 2021년 가을에 나왔으니 2026년 가을 EOL은 예정된 수순이다. 놀랄 일이 아니라 달력에 진작 적혀 있던 일인데, 이런 건 늘 마감 두 달 전에야 발등에 떨어진다. 우리 팀도 그랬다.

업그레이드, pg_upgrade냐 논리 복제냐

메이저 업그레이드 방법은 실무에서 사실상 두 갈래다 — pg_upgrade(빠르지만 다운타임 필요)와 논리 복제(logical replication) 기반 전환(다운타임 최소화, 준비 복잡). 데이터가 작고 잠깐 멈춰도 되면 전자가 압도적으로 간단하다. 24/7 서비스라 몇 초의 전환만 허용된다면 후자를 택한다. 둘을 나란히 놓으면 이렇다.

대부분의 팀엔 pg_upgrade면 충분하다. 관건은 반드시 사전 점검(--check)을 먼저 돌리는 것이다. 이 단계에서 호환 안 되는 데이터 타입, 사라진 함수, 확장 문제를 미리 잡을 수 있다. 나는 이 --check를 스테이징에서 프로덕션과 동일한 덤프로 최소 두 번은 리허설한 뒤에야 실서버에 손을 댄다.

# 1) 새 버전(예: 17)로 실제 전환 전, 호환성만 먼저 점검
/usr/lib/postgresql/17/bin/pg_upgrade \
  --old-datadir=/var/lib/postgresql/14/main \
  --new-datadir=/var/lib/postgresql/17/main \
  --old-bindir=/usr/lib/postgresql/14/bin \
  --new-bindir=/usr/lib/postgresql/17/bin \
  --check          # ← 점검만, 데이터는 건드리지 않음

# 2) 점검을 통과하면 실제 업그레이드
#    --link 는 파일을 복사 대신 하드링크로 연결해 매우 빠르지만
#    성공 후 구 데이터디렉터리로 롤백이 사실상 불가하니 주의
/usr/lib/postgresql/17/bin/pg_upgrade \
  --old-datadir=/var/lib/postgresql/14/main \
  --new-datadir=/var/lib/postgresql/17/main \
  --old-bindir=/usr/lib/postgresql/14/bin \
  --new-bindir=/usr/lib/postgresql/17/bin

# 3) 업그레이드 후 반드시 통계 재수집 — 안 하면 첫날 쿼리 플랜이 엉망
/usr/lib/postgresql/17/bin/vacuumdb --all --analyze-in-stages

마지막 vacuumdb --analyze-in-stages를 빼먹으면 업그레이드 직후 옵티마이저가 통계 없이 플랜을 짜서 멀쩡하던 쿼리가 갑자기 느려진다. pg_upgrade가 통계를 이어주지 않기 때문인데, 이건 문서에 있는데도 다들 첫 번째로 잊는 함정이다.

19에서 기대되는 것 ① 파티셔닝

여기서부터는 베타 기준 예상이라는 걸 다시 강조한다. 19에서 눈에 띄는 방향 하나는 파티셔닝(partitioning)의 완성도 향상이다. PostgreSQL의 선언적 파티셔닝은 10에서 도입된 뒤 버전마다 조금씩 다듬어져 왔는데, 오랫동안 아픈 손가락이던 부분들 — 파티션 프루닝(불필요한 파티션 건너뛰기)의 정밀도, 파티션이 많을 때의 계획 시간, 파티션 단위 조인·집계의 효율 — 이 계속 개선 대상에 오른다.

파티셔닝을 실제로 굴려본 사람은 안다. 파티션 수가 수백 개를 넘어가면 쿼리 실행보다 계획(planning) 단계가 병목이 되는 순간이 온다. 옵티마이저가 매번 모든 파티션을 훑어야 하기 때문이다. 이 계획 오버헤드를 줄이는 방향의 개선은 시계열·로그성 대용량 테이블을 다루는 입장에선 체감이 크다. 다만 반복하건대, 최종 릴리스 노트로 확정되기 전엔 "그렇게 될 것 같다"까지다.

-- 파티션 프루닝이 실제로 먹는지 확인하는 습관
-- EXPLAIN 에서 스캔되는 파티션이 조건에 맞는 것만 남아야 정상
EXPLAIN (ANALYZE, BUFFERS)
SELECT count(*) FROM events
WHERE created_at >= '2026-09-01' AND created_at < '2026-10-01';
-- 출력에 관련 없는 월 파티션이 잔뜩 뜨면 프루닝이 안 되는 것 →
-- 파티션 키를 조건에 직접 쓰고 있는지, 함수로 감싸지 않았는지 점검

19에서 기대되는 것 ② 논리 복제 강화

두 번째 방향은 논리 복제(logical replication)의 기능 확장이다. 논리 복제는 무중단 업그레이드와 이기종 간 데이터 이동의 핵심 도구인데, 매 버전 꾸준히 강해지고 있다. 최근 흐름을 보면 업그레이드 시 복제 슬롯 보존, 시퀀스 복제, 대형 트랜잭션 스트리밍, 충돌 처리 개선 같은 것들이 계속 다뤄진다. 19에서도 이 계열의 진전이 예상된다.

왜 개발자가 여기에 관심을 둬야 하냐면, 앞서 본 무중단 메이저 업그레이드가 바로 논리 복제 위에서 돌아가기 때문이다. 논리 복제가 강해질수록 "구 버전 → 신 버전"으로 데이터를 흘리며 마지막에 커넥션만 바꿔 끼우는 전환이 쉬워진다. 14 EOL 같은 상황에서 다운타임 없이 넘어가야 한다면, 이 기능의 성숙도가 곧 내 밤샘 여부를 결정한다.

-- 논리 복제 기반 업그레이드의 뼈대 (개념 예시)
-- [구 서버] 발행(publication) 생성
CREATE PUBLICATION pub_all FOR ALL TABLES;

-- [신 서버] 구독(subscription) 생성 → 초기 복사 후 실시간 반영 시작
CREATE SUBSCRIPTION sub_all
  CONNECTION 'host=old-db port=5432 dbname=app user=repl'
  PUBLICATION pub_all;

-- 지연이 0에 수렴하면(pg_stat_subscription 확인) 짧은 창에
-- 애플리케이션 커넥션을 신 서버로 전환 → 전환 순간만 수 초 다운타임
SELECT subname, latest_end_lsn, latest_end_time FROM pg_stat_subscription;

19에서 기대되는 것 ③ 모니터링 · pg_dump

세 번째 묶음은 운영 편의 쪽이다. 예상되는 방향은 크게 둘 — 모니터링 관측성 개선과 pg_dump 개선이다. 모니터링 쪽은 pg_stat_* 계열 통계 뷰에 새 지표가 붙거나 I/O·wait 이벤트 가시성이 좋아지는 형태로 매 버전 조금씩 확장돼 왔고, 19도 그 연장선으로 보인다. 관측성은 화려하진 않아도 장애 대응할 때 이게 있고 없고가 하늘과 땅이다.

pg_dump는 백업·마이그레이션의 기본 도구라 작은 개선도 파급이 크다. 대용량 덤프의 병렬 처리나 성능·안정성 개선이 논의 대상에 오른다. 이런 도구성 개선은 릴리스 노트에서 눈에 잘 안 띄지만, 새벽에 몇 백 기가짜리 덤프를 뜨는 사람에겐 제일 반가운 항목이다.

벡터 검색, 코어로 들어오나 (초기 신호)

가장 조심스럽게 다뤄야 할 대목이다. 결론부터 말하면 "코어에 벡터 검색이 정식 탑재된다"는 확정된 사실이 아니다. 다만 AI 워크로드가 폭발하면서 벡터 검색을 코어에서 더 잘 지원하자는 논의와 초기 신호가 관측되는 정도다. 지금 프로덕션에서 벡터를 쓰려면 여전히 pgvector 확장이 사실상 표준이고, 19가 나와도 당분간은 그럴 가능성이 높다.

이 주제는 과장 기사가 많아서 특히 조심해야 한다. "PostgreSQL 19가 벡터 DB를 잡아먹는다" 같은 헤드라인을 그대로 믿지 말자. 현실적으로 개발자가 할 일은 명확하다 — 지금은 pgvector로 하되, 코어 진전을 지켜보는 것. pgvector는 이미 충분히 실전적이라 당장 부족함이 없다.

-- 지금 벡터 검색의 표준: pgvector 확장
CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE docs (
  id     bigserial PRIMARY KEY,
  body   text,
  embedding vector(1536)          -- 임베딩 차원은 모델에 맞춰
);

-- 근사 최근접 검색용 HNSW 인덱스 (정확도/속도 균형이 좋음)
CREATE INDEX ON docs USING hnsw (embedding vector_cosine_ops);

-- 코사인 거리 기준 상위 5개 유사 문서
SELECT id, body
FROM docs
ORDER BY embedding <=> '[...query embedding...]'
LIMIT 5;

그래서 지금 뭘 하면 되나 — 체크리스트

정리하면 우선순위는 명확하다. 급한 것부터 순서대로다.

1. 이번 주: 8월 13일 마이너 릴리스(자기 계열의 .x)를 적용한다. 보안 28건이 걸려 있어 가장 급하다.
2. 이번 달: 14 인스턴스가 있다면 11월 12일 EOL 대비 업그레이드 계획을 확정한다. 시간이 빠듯하면 19를 기다리지 말고 16/17로 먼저 벗어난다.
3. 테스트 환경: 여유가 되면 19 베타를 깔아 확장 호환성·쿼리 플랜 변화를 미리 본다. 프로덕션 도입은 GA, 가능하면 19.1~19.2 이후로.
4. 업그레이드 리허설: pg_upgrade --check를 프로덕션 동일 덤프로 최소 두 번 돌리고, 끝나면 vacuumdb --analyze-in-stages를 잊지 않는다.
5. 벡터 계획: 벡터를 쓴다면 pgvector 버전·인덱스 재빌드 경로를 업그레이드 체크리스트에 포함한다.

새 버전은 설레는 소식이지만, 데이터베이스에서 진짜 중요한 건 늘 끝나는 것(EOL)과 고쳐진 것(보안 패치)이다. 19 구경은 나중에 해도 되지만, 14 EOL과 8월 마이너는 지금 손대야 한다. 순서를 헷갈리지 말자.

자주 묻는 질문

PostgreSQL 19는 지금 프로덕션에 써도 되나요?

권하지 않는다. 이 글 기준 19는 GA가 아니라 베타 3이고, GA는 2026년 9월 중 예정이다. 베타는 테스트·검증용이지 실서비스용이 아니다. 프로덕션은 GA 이후, 보수적으로는 자잘한 문제가 정리되는 19.1~19.2 마이너가 나온 뒤 도입하는 걸 권한다.

PostgreSQL 14를 계속 쓰면 어떻게 되나요?

2026년 11월 12일 EOL 이후로는 보안 패치와 버그 수정이 나오지 않는다. 서버가 멈추진 않지만 새로 발견되는 취약점에 무방비가 되고, 컴플라이언스 감사에서 문제가 된다. EOL 전에 지원되는 버전(16·17, 또는 GA 후 19)으로 올려야 한다.

8월 13일 마이너 릴리스는 꼭 지금 적용해야 하나요?

가급적 빨리 하는 게 맞다. 보안 취약점 28건과 버그 110개 이상이 걸려 있고, 마이너 업데이트는 데이터 포맷이 그대로라 대개 패키지 교체 후 재시작만으로 끝난다. 다운타임과 위험이 작은 반면 방치하면 알려진 취약점을 그대로 열어두는 셈이다.

14에서 19로 한 번에 건너뛰어 올려도 되나요?

버전 자체는 pg_upgrade로 여러 메이저를 건너뛰어 한 번에 올릴 수 있다. 다만 19는 아직 GA 전이라 지금은 대상이 아니다. 시간이 급하면 안정판 16/17로 먼저 올려 EOL을 벗어나고, 19가 여문 뒤 다음 창에서 올리는 2단계가 안전하다.

19에서 벡터 검색이 코어에 들어오나요?

확정된 사실이 아니다. AI 수요로 코어의 벡터 지원을 강화하자는 논의와 초기 신호가 있는 정도이고, 정식 탑재로 발표된 건 아니다. 지금도, 그리고 19가 나와도 당분간 실전 벡터 검색은 pgvector 확장이 표준이다. 코어 진전은 지켜보되 계획은 pgvector 기준으로 세우면 된다.

메이저 업그레이드에서 가장 흔한 실수는 뭔가요?

둘이다. 하나는 pg_upgrade 후 vacuumdb --analyze-in-stages로 통계를 다시 모으지 않아 쿼리 플랜이 망가지는 것. 다른 하나는 확장(pgvector·PostGIS 등)의 새 버전 지원을 확인하지 않고 올리는 것이다. 이 둘만 챙겨도 업그레이드 사고의 절반은 예방된다.

업그레이드 전에 무엇을 백업해야 하나요?

최소한 전체 논리 백업(pg_dumpall 또는 pg_dump)과, 가능하면 파일 레벨 스냅샷을 함께 확보하라. pg_upgrade를 --link로 돌리면 성공 후 원본으로 롤백이 사실상 불가하므로, 링크 모드를 쓸 거라면 백업은 선택이 아니라 필수다. 그리고 백업은 반드시 복원 테스트까지 해봐야 진짜 백업이다.