Postgres 16 대 17 대 18: 중요한 이득

세 가지 버전은 단일 전체 성능 수치로 구분되지 않습니다. 각각은 매번 다른 대상을 사용하여 아키텍처의 특정 지점을 수정합니다. Postgres 17용 대형 테이블, Postgres 18용 대기 시간이 긴 스토리지입니다. 아래 표에는 각 프로젝트의 세부 사항을 설명하기 전에 날짜가 기록된 검증 가능한 사실이 요약되어 있습니다.

출처: PostgreSQL 프로젝트(postgresql.org)의 공식 릴리스 노트. 각 주요 릴리스 이후 Microsoft Tech Community 및 Crunchy Data에서 게시한 분석을 상호 참조합니다. 2026년 8월 24일에 액세스함.

Postgres 17 이전에는 VACUUM이 정리할 데드 튜플 목록을 maintenance_work_mem크기의 간단한 배열로 저장했습니다. 문제는 계산 속도가 아니라 구조 자체였습니다. 이 테이블은 그 이상으로 아무리 구성해도 1GB 주변에서 정체되었습니다. 약 1억 7,800만 개가 넘는 데드 행이 있는 테이블에서 VACUUM은 여러 패스에서 루프를 반복해야 했으며, 각 패스는 전체 인덱스를 다시 읽어야 했습니다.

Postgres 17은 이 배열을 튜플 식별자를 저장하는 데 필요한 공간을 크게 압축하는 적응형 기수 트리인 TidStore라는 구조로 대체합니다. 프로젝트의 공식 릴리스 노트에는 기존 구조와 관련된 인공 천장 없이 VACUUM에서 사용하는 메모리가 경우에 따라 최대 20배까지 감소했음을 나타냅니다. 출처: PostgreSQL 17 공식 릴리스 노트, postgresql.org, 2024년 9월 26일. Microsoft Tech Community 및 Crunchy Data는 각각 릴리스 직후 이 변경 사항에 대한 기술적 분석을 게시했습니다. 둘 다 높은 삭제 또는 업데이트 속도로 수억 행의 테이블에 대한 구체적인 관심을 확인합니다.

이 프로젝트는 주로 특정 시나리오, 즉 삭제 또는 업데이트 비율이 높은 대규모 테이블에 도움이 됩니다. 이전에는 사용 가능한 메모리 부족으로 인해 VACUUM이 여러 번 실행되었습니다. 작은 테이블이나 주로 읽기 로드에서는 이득이 미미하거나 눈에 띄지 않습니다.

두 번째 Postgres 17 프로젝트에서는 트랜잭션 스냅샷 계산이라는 좀 더 신중한 사항을 다룹니다. 각 쿼리는 Postgres의 MVCC 가시성 규칙을 적용하기 위해 진행 중인 다른 트랜잭션이 무엇인지 알아야 합니다. 코어 수가 많고 활성 연결이 있는 시스템에서 이 계산으로 인해 공유 내부 구조에 대한 경합이 발생했습니다. 이는 프로젝트 참여자들이 오랫동안 문서화한 병목 현상입니다.

Postgres 17은 이러한 경합을 줄입니다. 이 효과는 주로 멀티 코어 하드웨어에서 동시 활성 연결이 많이 발생하는 높은 동시성 인스턴스에서 측정됩니다. 동시성 로드가 낮은 경우 Postgres 16과의 차이는 미미합니다. 이는 격리된 요청당 대기 시간을 줄이는 것이 아니라 확장성 프로젝트입니다.

이러한 이점은 연결 풀러를 대체하지 않으며 단순히 내부 비용을 줄여줍니다. 활성 연결 수가 이미 병목 현상을 일으키는 경우 주요 버전이 뒷자리를 차지합니다. max_connections 튜닝 가이드 및 PgBouncer 트랜잭션 모드 비교 이 주제를 더 자세히 살펴보세요.

2025년 9월 말에 출시된 Postgres 18은 보다 구조적인 문제를 해결합니다. 그때까지 모든 Postgres 디스크 읽기는 이를 요청한 프로세스를 차단했습니다. 새로운 비동기 입출력(AIO) 하위 시스템을 사용하면 프로세스가 여러 읽기를 병렬로 시작하고 각 읽기를 순차적으로 기다리는 대신 완료되는 동안 작업을 계속할 수 있습니다.

io_method 매개변수는 이 동작을 제어합니다. worker(I/O 전용 프로세스, 기본값) 또는 Linux의 io_uring(Postgres가 이 지원으로 컴파일된 경우). 순차 스캔, 비트맵 힙 스캔 및 VACUUM은 특히 대기 시간이 긴 스토리지(로컬 NVMe가 아닌 네트워크 디스크, 클라우드 볼륨)에서 첫 번째 수혜자입니다.

관리형 Postgres 제품을 제공하는 PlanetScale은 이 I/O 변경에 초점을 맞춘 자체 Postgres 17과 18 비교를 게시했습니다. 이는 우리가 여기서 독립적으로 재현한 수치가 아닌 자체 인프라에 대한 측정값입니다. 보편적인 백분율이 아닌 실제 부하에서 해당 주제를 테스트할 가치가 있다는 신호로 받아들이십시오.

Postgres 18의 일반화된 AIO는 고립된 변경이 아니라 Postgres 17에서 시작된 프로젝트를 계속합니다. 버전 17에서는 이미 스트리밍 I/O 인터페이스를 도입했지만 ANALYZE 및 순차 스캔으로 제한되었습니다. Postgres 18은 이와 동일한 논리를 VACUUM 및 비트맵 힙 스캔을 포함하여 더 넓은 범위의 작업으로 확장합니다. 따라서 두 버전은 I/O에 대한 두 개의 별도 베팅이 아니라 진행으로 읽혀집니다.

원시 성능을 직접적으로 다루지는 않더라도 세 가지 다른 Postgres 18 변경 사항은 모니터링할 가치가 있습니다.

다중 열 B-트리 인덱스에 대한 건너뛰기 스캔을 사용하면 쿼리가 헤드 열을 필터링하지 않는 경우에도 Postgres가 복합 인덱스를 사용할 수 있습니다. Postgres 18 이전에는 이 시나리오에서 테이블 전체를 스캔하거나 추가 전용 인덱스를 생성해야 하는 경우가 많았습니다.

생성된 가상 열(GENERATED ALWAYS AS (...) VIRTUAL)은 STORED이 지정되지 않은 경우 기본 동작이 됩니다. 가상 열은 디스크에 기록되는 것이 아니라 읽기 시 계산되므로 소스 행이 삽입되거나 업데이트될 때마다 기록되는 양이 줄어듭니다.

Postgres 18은 마침내 SCRAM, 인증서 또는 LDAP와 같은 기존 메커니즘과 함께 인증 측면(RFC 8628, 장치 흐름)에서 OAuth 2.0에 대한 지원을 추가합니다. 외부 OAuth/OIDC 공급자를 통해 이미 ID를 중앙 집중화한 모든 조직에 대한 관련 지점입니다.

Aurabase에서 테넌트 데이터베이스는 현재 Postgres 17이 아닌 16.15에서 실행됩니다. 이는 저장소에서 직접 확인할 수 있습니다. 참조 CNPG 이미지(docker/Postgres.CNPG.Dockerfile)는 공유 계층(docker/Postgres.Dockerfile)과 동일한 주요 버전인 다이제스트로 고정된 ghcr.io/cloudnative-pg/postgresql:16-standard-bookworm에서 시작합니다. 2026년 8월 24일에 확인됨.

코드에는 그 이유도 문서화되어 있습니다. k8s_tenant.rs의 수정 설명은 이전 폴백이 실수로 postgresql:17.2을 가리켰음을 설명합니다. 당시 표준 이미지에 pgVector가 포함되어 있지 않다는 이유는 확인 결과 거짓임이 밝혀졌습니다. 두 이미지 모두 플릿 클러스터에서 측정된 17.2에서 0.8.0, 16-standard-bookworm에서 0.8.5의 pgVector를 갖습니다.

주석 자체에 문서화된 실제 위험은 다른 곳에 있습니다. CloudNativePG는 클러스터가 생성된 후 주요 버전 다운그레이드를 금지합니다. Postgres 17에서 실수로 프로비저닝된 플릿은 되돌릴 수 없는 반면, Aurabase에서 엔드투엔드 검증된 모든 것은 Postgres 16에 있었습니다.

// TENANT_POSTGRES_IMAGE가 정의되지 않은 경우 주 버전이 유지됩니다.
let repli = "ghcr.io/cloudnative-pg/postgresql:16-standard-bookworm";

tracing::warn!(
    image = repli,
    "TENANT_POSTGRES_IMAGE non défini : repli sur la version validée."
);

이것은 Postgres 17에 대한 판단이 아닙니다. 이는 운영상의 신중함을 위한 정책입니다. 엔드투엔드 검증이 이루어질 때까지 프로덕션 제품군을 주요 버전으로 전환하지 마십시오. CloudNativePG 또는 동등한 Kubernetes 운영자를 통해 Postgres를 관리하는 모든 팀에도 동일한 추론이 적용됩니다. 문제는 예상되는 성능 향상뿐 아니라 문제가 발생하는 경우 돌아갈 수 있는 방법이기도 합니다.

지금 Postgres 17 또는 18로 마이그레이션해야 합니까?

세 가지 기준을 사용하면 보편적인 수치를 기다리지 않고 결정할 수 있습니다. 첫째, 가장 큰 테이블의 크기 및 변형률입니다. VACUUM이 이미 여러 단계에서 실행 중인 경우 Postgres 17 메모리 작업 사이트가 해당 사례에 직접 적용됩니다. 그런 다음 스토리지: 대기 시간이 짧은 로컬 SSD에서 Postgres 18의 비동기 I/O는 네트워크 볼륨보다 적은 양을 제공합니다. 마지막으로, 주요 다운그레이드를 금지하는 운영자의 경우 일회용 환경에서 먼저 테스트하는 것은 선택적인 예방 조치가 아닙니다.

구체적으로, Kubernetes 운영자가 관리하는 모든 플릿에는 동일한 규칙이 적용됩니다. 먼저 대상 릴리스에서 테스트 클러스터를 프로비저닝한 다음 프로덕션의 로드 대표를 재생합니다. 릴리스 노트를 읽는 것뿐만 아니라 이 테스트가 처음부터 끝까지 검증된 후에만 실제 클러스터를 만지십시오. 귀하의 결정이 이러한 유형의 변화를 흡수하기 위해 전용 베이스와 공유 베이스 사이의 선택과 관련이 있는 경우, 당사의 기사 전용 및 공유 베이스에서 이 각도를 살펴봅니다.

Postgres 16, 17, 18 사이의 선택은 단순히 어떤 버전이 "가장 빠른"가에 관한 것이 아닙니다. Postgres 17은 대규모 테이블의 실제 구조적 VACUUM 문제를 수정하고 높은 동시성에서 경합을 줄입니다. Postgres 18은 일반화하기 전에 실제 로드 및 스토리지에 대한 테스트가 필요한 아키텍처 변경인 비동기 I/O를 통해 더욱 발전했습니다.

The criterion most often forgotten is not performance, it is reversibility. On an operator like CloudNativePG, a major version upgrade is not undone after the fact. Before switching over a production fleet, the real question is not only the expected gain, it is also the return path if the test fails. If you are preparing for this version upgrade, our Postgres tuning checklist in production details the settings to revalidate after a major version change.