PostgreSQL 19 Beta 4: 빠르다는 말보다 먼저 볼 업그레이드 변화

PostgreSQL 19 Beta 4는 새 기능을 시험할 기회이며, 운영 데이터베이스를 바로 교체하라는 신호는 아닙니다. 새 버전에서 달라지는 실행 계획과 기본 설정을 현재 업무의 쿼리로 비교해야 합니다. 버전 숫자가 높다는 사실만으로 모든 조회가 빨라지는 것은 아닙니다.

프로젝트는 2026년 9월 24일 Beta 4를 발표했습니다. 발표는 베타 기간에 세부 사항이 바뀔 수 있고, 다음 RC와 정식 공개 일정은 검증에 따라 결정된다고 설명합니다. 이 글은 해당 발표와 10월 8일 확인한 문서를 기준으로 하며 정식 출시일을 확정하지 않습니다. PostgreSQL 19 Beta 4 발표

실제 쿼리에 영향을 줄 세 가지 변화

현재 release notes에서는 NULL이 없는 경우의 NOT IN 최적화, 일부 조인·집계 계획 개선, JIT 기본 동작 변경과 관측 항목 변경 등을 확인할 수 있습니다. PostgreSQL 19 release notes

새 기능 목록보다 내 서비스에서 어떤 경로가 해당하는지 찾는 것이 실용적입니다. 특히 버전별 기본값 차이를 모른 채 같은 부하를 비교하면 무엇이 성능에 영향을 줬는지 해석하기 어렵습니다.

NOT IN과 NULL을 먼저 이해하기

NOT IN을 NOT EXISTS로 바꾸는 것은 단순한 속도 개선 공식이 아닙니다. NULL이 들어 있을 때 결과 의미가 달라질 수 있습니다. PostgreSQL 하위 쿼리와 NULL 설명을 참고하세요. 다음은 SQL의 의미를 확인하는 작은 예제이며 새 버전만의 기능이 아닙니다.

WITH candidates(id) AS (VALUES (1), (2), (3)),
     excluded(id) AS (VALUES (2), (NULL::integer))
SELECT id
FROM candidates
WHERE id NOT IN (SELECT id FROM excluded);
-- 이 조건으로는 반환되는 행이 없습니다.

WITH candidates(id) AS (VALUES (1), (2), (3)),
     excluded(id) AS (VALUES (2), (NULL::integer))
SELECT c.id
FROM candidates AS c
WHERE NOT EXISTS (SELECT 1 FROM excluded AS e WHERE e.id = c.id);
-- 이 예시에서는 1과 3이 대상입니다.

어느 표현이 업무 의도에 맞는지 먼저 결정해야 합니다. 새 옵티마이저의 개선을 시험한다는 이유로 NULL 의미를 바꾸면, 쿼리는 빨라져도 결과가 틀릴 수 있습니다.

비교용 데이터는 복사본으로 준비

베타 평가에는 운영과 분리된 데이터와 서버를 사용하세요. 개인정보가 필요한 범위를 줄이고, 실제 데이터의 분포·인덱스·통계는 최대한 비교 가능한 조건으로 맞춥니다. 데이터 개수만 같고 특정 값의 편중이 다르면 실행 계획이 달라질 수 있습니다.

같은 SQL에 같은 바인딩 값을 사용하고, 반환 행 수와 중요한 결과를 먼저 대조하세요. 그다음 EXPLAIN ANALYZE 읽는 법을 참고해 계획·실행 시간·버퍼 접근을 비교합니다.

SELECT version();
SHOW jit;
-- 아래에는 변경 작업이 아닌 실제 비교 대상 SELECT를 사용
EXPLAIN (ANALYZE, BUFFERS) SELECT 1;

SELECT 1은 명령 형태를 확인하는 예이며 업무 성능을 측정하는 쿼리가 아닙니다. ANALYZE는 쿼리를 실제 실행하므로 변경 쿼리를 운영에서 실험하는 방식으로 쓰지 마세요. 무거운 읽기도 자원을 사용하므로 재현 환경에서 시험하는 편이 좋습니다.

JIT·워밍업·동시성을 함께 기록

현재 19 문서의 JIT 기본 변화가 해당 업무에 영향을 주는지 확인하세요. 짧은 요청을 자주 처리하는 앱과 큰 분석 쿼리는 요구가 다릅니다. 같은 쿼리라도 캐시가 차가울 때와 준비된 뒤의 비용이 달라질 수 있습니다.

평가 기록에는 버전, 주요 설정, 동시 요청 수, 실행 횟수, 데이터 상태를 함께 적으세요. 한 번의 실행 시간보다 반복 결과와 p95·p99 같은 서비스 지연도 확인하는 편이 좋습니다. 평균이 줄어도 특정 쿼리의 지연이 늘 수 있습니다.

확장·클라이언트·모니터링은 별도 확인

메이저 업그레이드는 서버 바이너리만 바꾸는 일이 아닙니다. 사용하는 확장의 19 지원 여부, 인증과 연결, 드라이버, pool, backup 도구와 모니터링 SQL을 확인하세요.

release notes는 통계 뷰의 필드 이름 등 호환성에 영향을 주는 변화도 담고 있습니다. 데이터 조회는 정상인데 대시보드 수집기가 실패하면 장애를 늦게 발견할 수 있습니다. 연결 풀 고갈과 복제 지연 관측의 경로도 버전 변경 뒤 재확인할 대상입니다.

복원 리허설이 끝나야 전환을 판단

공식 문서는 이전 메이저 버전에서 데이터 이전 시 pg_upgrade, dump/restore 등 적절한 이전 절차가 필요하다고 설명합니다. 데이터를 가진 디렉터리에 새 바이너리를 연결하면 안전하게 자동 업그레이드된다고 가정하지 마세요.

리허설에서는 다음을 기록합니다.

1. 데이터 이전과 검증에 걸린 시간.
2. 확장·스키마·권한·주요 쿼리 결과.
3. 백업에서 별도 환경으로 복구한 결과.
4. 전환 후 새로 들어온 변경을 되돌릴 때의 처리.
5. 전환을 중단할 실패 기준과 책임자.

예전 서버가 남아 있다는 것만으로 롤백이 완성되지는 않습니다. 새 서버에만 반영된 변경을 어떻게 처리할지 결정해야 하기 때문입니다. 베타 평가와 운영 전환 판단은 분리해서 기록하세요.

자주 묻는 질문

PostgreSQL 19 Beta 4는 정식 버전인가요?

이 글의 근거인 9월 24일 발표는 베타 공개입니다. 설치 시점의 공식 발표와 버전 상태를 다시 확인하세요.

NOT IN을 전부 NOT EXISTS로 바꾸면 빨라지나요?

NULL과 업무 의미를 먼저 확인해야 합니다. 반환 결과와 실행 계획을 대조하지 않고 일괄 변경할 수 없습니다.

버전만 바꾸고 데이터 디렉터리를 그대로 쓰면 되나요?

메이저 버전 이전에는 지원되는 데이터 이전 절차와 확장 호환 확인이 필요합니다. 복사본에서 공식 절차를 검증하세요.

참고 자료

• Beta 4 발표 — 2026-09-24.
• PostgreSQL 19 release notes.
• PostgreSQL 공식 최신 발표.

2026년 10월 8일 확인. 베타 기능·계획은 바뀔 수 있으므로 적용 시점의 release notes와 정식 공개 상태를 다시 확인하세요.