💡 글의 핵심 3줄 요약

1. PostgreSQL 18은 여러 읽기 요청을 함께 처리하는 비동기 I/O를 도입해 순차 스캔, 비트맵 힙 스캔, VACUUM의 처리량을 개선했습니다.
2. B-tree Skip Scan은 복합 인덱스의 선두 열 조건이 없어도 뒤쪽 열을 활용할 기회를 넓히지만, 모든 쿼리를 자동으로 빠르게 만들지는 않습니다.
3. 시간순 UUIDv7, 가상 생성 열, 업그레이드 시 통계 유지가 추가됐으며 실제 전환은 실행 계획과 운영 부하를 재측정한 뒤 결정해야 합니다.

PostgreSQL 18, 데이터베이스 성능의 병목을 어디서 줄였을까

데이터베이스 버전이 올라갈 때마다 “더 빨라졌다”는 문구가 등장합니다. 하지만 운영하는 입장에서는 무엇이, 어떤 조건에서 빨라졌는지가 더 중요합니다. 인덱스만 타는 짧은 조회와 수백 GB 테이블을 훑는 분석 쿼리는 병목이 전혀 다르기 때문입니다.

2025년 9월 25일 공개된 PostgreSQL 18은 저장장치 읽기 경로를 손본 비동기 I/O, 복합 B-tree 인덱스의 활용 범위를 넓힌 Skip Scan, 시간 순서를 담는 UUIDv7을 주요 변화로 내세웠습니다. 공식 발표는 특정 저장장치 읽기 작업에서 최대 3배 향상을 관찰했다고 밝혔지만, 이는 모든 애플리케이션이 3배 빨라진다는 의미가 아닙니다.

이번 글에서는 기능 목록을 나열하기보다 각 변화가 해결하는 병목과 확인해야 할 실행 계획을 중심으로 살펴보겠습니다.

PostgreSQL 18 비동기 I/O는 기다림을 겹쳐 처리합니다

기존 방식에서는 운영체제의 readahead가 앞으로 필요할 블록을 잘 예측해 주길 기대하는 부분이 컸습니다. 하지만 운영체제는 데이터베이스의 실행 계획과 페이지 접근 의도를 모두 알지 못합니다. 읽기 요청 하나가 끝나기를 기다린 다음 다음 요청을 내는 구간이 많으면 빠른 SSD도 충분히 활용하지 못합니다.

PostgreSQL 18의 비동기 I/O 하위 시스템은 백엔드가 여러 읽기 요청을 큐에 넣어 저장장치의 대기 시간을 겹칠 수 있게 합니다. 순차 스캔, 비트맵 힙 스캔, VACUUM 등이 혜택을 받습니다. 창구 한 곳에서 서류 한 장이 끝날 때까지 기다리는 대신 여러 창구에 일을 나눠 놓는 모습과 비슷합니다.

io_method 선택은 운영체제와 빌드 조건을 따릅니다

io_method에는 worker, io_uring, sync가 있습니다. 기본값인 worker는 I/O 작업 프로세스를 사용합니다. Linux의 io_uring을 쓰려면 PostgreSQL이 liburing 지원으로 빌드되어 있어야 합니다. sync는 비동기 처리 대상 작업을 동기 방식으로 실행합니다.

여기서 곧장 io_uring이 항상 가장 빠르다고 결론 내리면 안 됩니다. 저장장치, 커널, 파일시스템, 컨테이너 제한과 쿼리 유형에 따라 결과가 달라집니다. pg_aios 뷰와 시스템 I/O 지표를 함께 보고, 실제 데이터 크기의 순차 스캔과 VACUUM으로 비교해야 합니다.

공식 발표의 최대 3배라는 수치도 “특정 시나리오에서 관찰된 상한”으로 읽는 편이 정확합니다. 데이터가 이미 shared buffers나 운영체제 캐시에 있다면 저장장치 대기를 줄이는 효과가 작을 수 있습니다. 반대로 캐시보다 큰 테이블을 자주 읽는 워크로드라면 차이가 더 잘 드러납니다.

PostgreSQL 18 Skip Scan은 복합 인덱스의 빈틈을 줄입니다

(region, created_at) 복합 B-tree 인덱스가 있는데 쿼리는 created_at만 조건으로 사용한다고 가정해 보겠습니다. 이전에는 선두 열인 region 조건이 없어 인덱스를 효율적으로 쓰기 어려운 경우가 많았습니다. PostgreSQL 18의 Skip Scan은 region의 가능한 값을 건너가며 뒤쪽 열 조건을 활용하는 계획을 선택할 수 있습니다.

Skip Scan이 인덱스 설계를 없애주지는 않습니다

선두 열의 고유 값이 적고 뒤쪽 열 조건이 결과를 크게 좁힐 때 유리할 가능성이 높습니다. 반대로 선두 열의 카디널리티가 매우 크거나 조회 범위가 넓다면 반복 탐색 비용이 커져 순차 스캔이 더 나을 수 있습니다. 옵티마이저는 통계를 바탕으로 비용을 비교합니다.

따라서 기존 인덱스를 바로 삭제해서는 안 됩니다. 대표 쿼리에 EXPLAIN (ANALYZE, BUFFERS)를 실행해 실제 시간, 읽은 버퍼, 반환 행 수를 확인하세요. 운영 데이터의 분포와 비슷한 환경에서 통계를 갱신한 뒤 비교해야 결과를 믿을 수 있습니다.

Skip Scan의 실용적인 장점은 “복합 인덱스 하나가 모든 조건을 해결한다”가 아니라, 기존 인덱스를 활용할 수 있는 선택지가 늘었다는 데 있습니다. 쓰기 비용이 큰 중복 인덱스를 줄일 기회가 생길 수 있지만, 결정은 관찰된 실행 계획 뒤에 와야 합니다.

PostgreSQL 18 UUIDv7은 식별자와 인덱스 지역성을 함께 봅니다

무작위 UUIDv4는 여러 시스템에서 충돌 걱정 없이 ID를 만들기 좋지만, 새 값이 B-tree 곳곳에 흩어집니다. 쓰기량이 많으면 페이지 분할과 캐시 지역성 측면에서 순차 키보다 불리할 수 있습니다. PostgreSQL 18은 RFC 9562 기반의 uuidv7()을 기본 함수로 제공합니다.

UUIDv7은 밀리초 단위 시간 정보와 임의 값을 조합해 대체로 시간순 정렬이 가능합니다. 분산 환경의 UUID 장점을 유지하면서 새 레코드가 인덱스의 가까운 영역에 들어갈 가능성을 높입니다. uuidv7()로 생성하고 uuid_extract_timestamp()로 시간 부분을 확인할 수 있습니다.

UUIDv7도 생성 시각과 보안 경계를 대신하지 않습니다

정렬 가능하다는 말은 전역적으로 완벽한 순서를 보장한다는 뜻이 아닙니다. 여러 노드의 시계 오차와 같은 밀리초 안의 값이 존재합니다. 엄격한 업무 순서는 별도 시퀀스나 이벤트 순서 규칙으로 관리해야 합니다.

또한 식별자에서 대략적인 생성 시각을 추정할 수 있다는 특성이 공개 API에 적합한지 검토해야 합니다. 생성 시각은 명시적인 created_at 열로 보관하는 편이 검색, 시간대 처리와 데이터 정책에 더 분명합니다. UUIDv7은 기본 키의 한 선택지이지 감사 로그는 아닙니다.

PostgreSQL 18 업그레이드는 계획 안정성을 함께 점검하세요

PostgreSQL 18에서는 pg_upgrade가 옵티마이저 통계를 유지해 업그레이드 직후 통계를 다시 모으는 부담을 줄입니다. 가상 생성 열이 기본이 되었고, DML의 RETURNING에서 OLD와 NEW 값을 명시적으로 다룰 수 있으며 OAuth 2.0 인증도 추가됐습니다.

편리한 변화가 많아도 메이저 업그레이드는 자동 성능 패치가 아닙니다. 확장 모듈 호환성, 드라이버, 백업 복구, 복제 구성을 먼저 확인하고 리허설해야 합니다. 같은 SQL도 새 옵티마이저에서 다른 계획을 선택할 수 있으므로 느린 쿼리 상위 목록과 기준 지연 시간을 전환 전에 저장해 두는 것이 좋습니다.

테스트는 단순 연결 확인에서 끝내지 마세요. 읽기 중심, 쓰기 중심, 배치와 VACUUM이 겹치는 시간대를 재현하고 p95 지연과 IOPS, CPU, WAL 발생량을 비교해야 합니다. 비동기 I/O의 이득이 다른 자원의 병목으로 이동했는지도 확인해야 합니다.

결론: PostgreSQL 18의 변화는 측정할 도구를 더해 줍니다

PostgreSQL 18의 핵심은 저장장치 대기를 겹치고, 복합 인덱스의 탐색 가능성을 넓히며, 분산 ID의 인덱스 지역성을 개선한 데 있습니다. 서로 다른 기능처럼 보이지만 모두 데이터가 실제 하드웨어를 오가는 비용을 줄이려는 변화입니다.

그렇다고 버전만 올리면 모든 쿼리가 빨라지지는 않습니다. 비동기 I/O는 디스크 읽기가 병목일 때, Skip Scan은 데이터 분포가 맞을 때, UUIDv7은 키 생성 전략과 쓰기 패턴이 맞을 때 효과를 냅니다.

가장 현실적인 접근은 업그레이드 전후의 실행 계획과 운영 지표를 같은 조건에서 비교하는 것입니다. PostgreSQL 18은 좋은 선택지를 제공하지만, 어떤 선택지가 내 서비스에 맞는지는 여전히 데이터가 답합니다. 릴리스 노트를 출발점으로 삼고 벤치마크를 결론으로 삼으세요.

참고 자료

• PostgreSQL 공식 발표: PostgreSQL 18 Released
• PostgreSQL 18 릴리스 노트
• PostgreSQL 18 비동기 I/O 설정
• PostgreSQL 18 UUID 함수